We have a saga that has only been listening to events from a single context. The saga needs to be changed to handle an event in a different context, which we can do by changing the configuration to use a MultiStreamableMessageSource.
After changing the configuration though, the tracking token will no longer be compatible. The existing tracking token is a GlobalSequenceTrackingToken, but it will probably then require a MultiSourceTrackingToken.
The question is: is there a recommended approach for making this change?
My initial thought was to write an SQL script to manually fiddle with the token in the token_entry table, but maybe there’s a better way?
Thanks for posting your question here. The only thing you need to do here is to delete all instances of GlobalSequenceTrackingToken for that Saga. By default, a Saga will start from the head of the event stream so if there is no token, a new token (in this case the MultiSourceTrackingToken) will be automatically created. If you don’t want to depend on default behavior, you can also set the token in the configuration yourself using createHeadToken() or createTokenAt() or createTokenSince()
Thanks for your answer, but I do have a follow-on question regarding this approach.
When the saga restarts from the head of the event stream, will it know not to process events that have already been processed? I would have thought that by deleting the tracking token entirely it would process all events again. This is not something we do not want to happen. i.e. it will cause commands to be sent from the saga that have already been sent.
I agree this is a bit confusing, the head of the event stream means after the last event, so it will not process events that were already there. You can be sure that the commands will not be sent again.