Introducing a newly revised Saga

Hi, I’m testing the ability to spin up a new saga instance (with new workflow logic and new events) in the middle of a running transaction to see what the behavior is.

If I kick off a transaction via the EventGateway where a few events/commands have been processed, and then I restart the saga manager mid-flight, the saga manager will pick up where it left off and the transaction will complete successfully.

Great, but what if instead I’d like to restart the saga manager with either (1) a new @Revision or (2) a new SAGA_TYPE, where the saga may introduce more workflow events. Can I still expect this new saga to complete the existing transaction? My attempts at doing this fail, where even changing the revision number causes the transaction not to complete. Is there support for what I’m trying to accomplish? I’ve read some of the posts about upcasting Sagas and I’m not sure if that aligns with what I’m describing here. What’s the migration strategy for introducing new workflows?

Ok, so after a bit more discussion with my team, it appears that we’re more concerned with being “revision-aware,” such that if we re-deploy and introduce the same SAGA_TYPE, but with a new @Revision, how can we still successfully process mid-flight transactions associated with the last revision in addition to the new transactions coming in. This may require access to current revision my saga is running, the revision associated with the mid-flight transaction, and some conditional logic to be implemented in the @SagaEventHandlers based on those revisions. Any thoughts?

Hi Ryan,

I think I can piece together your scenario, but I am missing some crucial pointers to be 100% sure what you are actually talking about.
Without diving into those though (guessing I can make the right assumption here), I will just go ahead with giving my recommendation when it comes to changing a Saga between production releases.

As you have rightfully put it, you are essentially changing a Saga, of which several would likely be serialized and stored in the Saga Store, into a new revision.
An option in here is to write upcasters to upcast the Saga instance from one revision to another.
Although doable (I have done this in the past), I can’t say it is a pleasant operation at the moment.

It requires quite some custom code on your end, either in the Serializer or in the SagaStore/SagaRepository to change a Saga from an older to a newer version.
Added, you will be required to build the Upcaster chain on your end too, as the current interfaces focus heavily on Event upcasting.
So, should you upcast a Saga? It is a fun and cool exercise to go through, but there are more pragmatic solutions out there.

The more efficient route you can take on your end is by keeping the old Saga implementation around. Let’s call it FooSaga_v1 for ease of explanation.
Now, you and the team have deduced that FooSaga_v1 doesn’t completely cut it and some additional state or event handlers are needed to correctly reflect this new approach.
Instead of adjusting FooSaga_v1 into FooSaga_v2, I would suggest adding FooSaga_v2 alongside FooSaga_v1.
Key here is to ensure not both v1 and v2 start new Sagas/Transaction upon releasing your product, so you will have to remove the @StartSaga annotation from the old version.

Doing so will mean your old Sagas keep running the complex business transaction they used to do, ending whenever this ends.
As soon as no more FooSaga_v1 entries are present in the saga_entry table you can simply drop the implementation in favor of v2.

That’s my two cents to this scenario. Hope this helps you and your team out Ryan!

Cheers,
Steven

PS. It is important to note that this mailing list will be discontinued as specified in this thread.
Instead of this mailing list we have moved over to use a forum style of communication, at https://discuss.axoniq.io/.

Hope to see you there!

Mind blown. I didn’t even think of removing the @StartSaga annotation. This is exactly what needs to happen. Thank you Steven!

Hi Ryan,

No worries Ryan, that’s what this forum is for right.

Glad to have been of help!

Cheers,
Steven