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