Changing saga behavior and handling past events

Imported from Google Groups
1

Hello,

Hoping I can ask these questions without any code samples. I have two questions regarding the behavior of sagas. As we’re developing our application we are of course refining our saga business logic and conditions.

1.) Say we have a saga called CreateAccountSaga. It’s triggered from an AccountRequestedEvent, and we expect an event to come through a few days later to conclude its lifecycle. The handler function runs, and the association is created. The saga is now waiting for that event coming soon. If we deploy a change to this business logic (e.g. in the first handler, or maybe the later one), does it start from scratch when it gets brought to life again on that redeploy? Which parts of the saga are we allowed to modify once it’s basically been started for a particular transaction?

2.) I just want to confirm this one. If you start an application with no tracking token and that CreateAccountSaga, will it pick up all the AccountRequestedEvents coming through on startup and initialize those sagas? Or will it only initialize sagas that have already been placed in the SagaStore?

I hope these questions make some sense. Just want to make sure we are treating them correctly. Thanks!

2

Hi Tom,

(we already discussed these in person, but sending a response for the record)

  1. Saga state is persisted in between calls. If you change your business logic, these will be applied for new events only. Note that the new class does need to be compatible with the state already serialized in the saga store.

  2. By default, processors will start from the beginning of the stream. That means your Sagas will be invoked for all historic events, too. If you want to change that, set the initialTrackingToken for your processor to the “head token”. Note that replays don’t affect Sagas. They will ignore all events that have been marked as a “redelivery”.

Cheers,