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.

And since 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.

• Changed – InvisibilityTimeout option now doesn’t have any effect when job is processed on an active server.
• Fixed – Various race conditions in FetchedJobsWatcher that 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.StrongName is deprecated now and will be removed in 3.0.