This is an important release that makes timeout detection much more robust. First of all, Redis server itself now acts as a single time authority for performing timeout checks for both jobs and servers rather than UTC time of a current Hangfire Server. So you don’t need to use synchronized clocks to prevent false positives for timeout checks.
Next change is related to the
InvisibilityTimeout logic and you are no longer required to calculate it, depending on maximal job execution time. This timeout option now does not affect background jobs in the
Processing state as they are considered to be faulted only when its processing server becomes inactive (i.e. removed due to graceful shutdown or due to timeout). So you can use now default value (5 minutes) for this option instead of having a custom one in 99% cases.
FetchedJobsWatcher component that’s responsible for re-queueing background jobs back to the queue due to timeouts is now fully transactional to prevent some other tricky race conditions that may lead to unnecessary job re-queues.
Hangfire.Pro.Redis.StrongName package is the same as
Hangfire.Pro.Redis starting from version 2.3.0, it’s now considered to be deprecated. You can safely switch to
Hangfire.Pro.Redis without introducing any dependency changes to your application, because Redis client is internalized even in .NET Standard versions.
InvisibilityTimeoutoption now doesn’t have any effect when job is processed on an active server.
Fixed – Various race conditions in
FetchedJobsWatcherthat lead to unnecessary re-queues.
- Fixed – False positives for invisibility timeout checks when servers’ clocks aren’t synchronized.
- Fixed – False positives for server timeout checks when servers use non-synchronized clocks.
Deprecated – Package
Hangfire.Pro.Redis.StrongNameis deprecated now and will be removed in 3.0.