Multiple HangFire Databases

This is a bit of an edge case that occurs after a new code deployment of our web application and HangFire service.

Our application architecture is a web app and two HangFire Windows Services. When we deploy new code we update the web app but only one the Windows services. Both the web app and the newly deployed Windows service are running against a new instance of the HangFire database. So far so good. However, the Windows Service which was NOT updated is running against the previous instance of the HangFire database with the older code base. This is by design. It allows us to do code deploys while still processing jobs that are long running on the older HangFire database instance. NOTE: Some of our jobs take hours to run so interrupting them and starting over just isn’t an option.

The issue is that sometimes, not often, but sometimes the user has a need to cancel a job that’s running on that older instance of the HangFire database. HangFire storage, however, appears to setup storage once and globally. If I switch which storage object I’m using (or connection string) in a method call for instance, then that connection string switch will affect HangFire globally in the web app, which is not what I want to do.

I’m wondering if there is a way to setup the storage HangFire but do so on a bit more of a localized basis.

May have found the answer. Looking at the source code I see there is a BackgroundJobClient that would allow me to specify a JobStorage object. I think this may be the way to go. It looks as if I could add an extension object BackgroundJob that would take a storage object so that it could instantiate a BackgroundJobClient object instead of getting one from the ClientFactory delegate function