Job versioning/evolution of job types

question
1

Hi,

what is the recommended way to deal with evolution of job and job parameter types once you have Hangfire (with SQL Server storage) running in production?

As an example, say you have an application running with Hangfire that has an INotificationProcessor job type. Now, for the next version, you want to refactor that job type - give it a new name, change its parameter types, or move it to a new assembly. If you simply do this and deploy the new version to production, you’ll get errors whenever processing an old job as it can no longer be deserialized.

Is there any way to tell Hangfire how to “upcast” an old serialized job to a new version? Or a recommendation about how to migrate serialized jobs in the database when releasing a new version?

(I guess I could reimplement Hangfire.SqlServer.SqlServerConnection, but this seems like a lot of complexity for a common scenario.)

2

Seems the new type resolution feature in https://www.hangfire.io/blog/2019/01/28/hangfire-1.6.22.html is one step towards better versioning.

3

@odinserj May I ask if there are other plans for versioning/upcasting, e.g., in 1.7?

4

How I usually handle this since the contract of the job is actually changing is create a new method with the new parameters and if the old method is compatible, I call the new method from the old one and decorate the old one that it will be obsolete. Then, after some period of time where I know there aren’t anymore jobs with the old definition out there, I go in and delete the old method entirely. Now, if your changes are only to the ctor and you use an IoC, it should just work without issues. The issue falls when the job method signature changes.

1 Like