Support dynamic modification at the job payload

[diegobernardes]

Let's assume that a given struct that represents a job is updated in a way that already enqueued messages are not compatible anymore. There is not much one can do at this situation, those enqueued jobs will be lost. Yes, this kind of change can be done with multi-step updates, but this approach usually takes longer and it's trickier to be done correctly since you need to guarantee that all old messages has successfully being processed.

Erlang has solved this really well and I would like to propose the same approach on River. There is a function called code_change/3 that is used during hot updates to modify the previous state into a new one that is expected on the new module that is being loaded.

River could do something similar by calling a fallback handler to transform the data in case the deserialization function returns an error.

[brandur]

Yeah, it's an interesting idea.

At the top, I want to make sure to link our article on changing job args safely, which describes a couple alternatives for how to do this without any callbacks:

https://riverqueue.com/docs/changing-job-args

I'd think of this a little differently than Erlang's code_change which is really about hot code reloading. This would be more like a callback for a data migration to apply, but maybe that's what you had in mind.

Reminds me a little of our version change framework back at Stripe.

[brandur]

@diegobernardes Hey I opened riverqueue/rivercontrib#39 over in our contrib modules to demonstrate how a version change framework might look. It's a fairly lightweight thing to do (to make a smaller one anyway), so I think a demo in contrib might be a nice home for this. Is this close to what you'd envisioned?