How to avoid recurring job version conflicts

sql-server
aspnetcore
recurring
Tags: #<Tag:0x00007f8b99dac588> #<Tag:0x00007f8b99dbfc50> #<Tag:0x00007f8b99dbf598>

#1

Hi,
I’m using Hangfire for a .Net Core application, storing job data in an SQL database.

I have a number of recurring jobs that get set during startup using the RecurringJob.AddOrUpdate() call.
I am trying to find a way to fix JobLoadExceptions that occur from those jobs when I deploy new versions of my application.

When I deploy a new version of my application, there is a brief period where the existing version is running live, and the new version is running in a pre-live slot, so I can test without it taking traffic. During this time, both live and pre-live instances are accessing the same database.

To the best of my understanding, when the pre-live instances start up, they update the job data in the Hangfire.Hash table, part of which is updating the version number of the application.
Then the live instances (old version) try to read that job information and fail because they can’t handle the jobs being specified for a different version of the app.

Is there a recommended way to avoid having applications trying to process jobs for a different version of the app?
I have considered adding a version suffix to the queue name or the job name.
I have also not been able to find much helpful information on what sort of affect it would have to leave jobs for the old version in the enqueued state after that version of the app is deleted and there are no servers processing for those jobs?

Are there any tips or use cases where people have gotten around this sort of an issue before?


#2

I would say the easiest is to just set up a separate “pre-live” Hangfire SQL server. So you don’t mix your “live” and “pre-live” environments.

Other than that it is hard to say anything without knowing how exact you are using the recurring jobs. Are they calling a method that you are changing? Or do they contain the actual code you want executed?