Users cannot easily refactor running sagas

[udidahan]

When developers apply refactoring techniques, as for example moving a saga class from a namespace to a different one, they're introducing a breaking change that is hard to deploy in production if they have running saga instances.

Sample scenario

Incoming stack overflow communication:

I'd like to refactor some of my sagas and messages and move them to a new namespace. I can't clear out the existing worker queues and need to have the old saga/messages still work until they are all gone. I won't be changing any behaviour of the saga/messages just the namespace, is there an easy way to bulk update these so that the old saga/messages can continue to process correctly.

More info

• Related Saga Headers

[SimonCropp]

I believe this can be handled purely with header manipulations of incoming messages and a migration script per persistence

[Scooletz]

@SimonCropp how about an attribute that preserves the old namespace and name?

[SagaNameAttribute ("Original.Name.Space", "OriginalTypeName")]
public class SagaThatHasItsNamespaceChanged 
{
}

[SimonCropp]

@Scooletz and yes that would work as a fully supported feature approach

[andreasohlund]

agreed, there seems to be 2 parts to the original request by the SO user

I'd like to refactor some of my sagas and messages and move them to a new namespace.

1. They like to rename messages/move namespaces

Here I think we can provide generic guidance using mutators/serializer etc to get this done. Perhaps a timeboxed effort that tries a few message refactoring scenarios.

Side note: We have a similar issue to figure out how painful (or if its even possible) to move handlers btw endpoints so there is definitely a theme of "how to refactor existing systems" that DevEx could take a more complete look at.

Should we raise a new issue for this?

2. They like to rename sagas/move namespaces

This seems to require collaboration with the persister in some form, either offline scripts or some runtime support for "redirecting" from one saga type to another. I have a faint memory that SQLP have support for this but can't find any doco. First steps here could be a TF to actually try a few scenarios and see if its actually possible to refactor sagas. If yes we can extract some guidance, add it to the saga tutorial etc.

If no than we can consider modifying individual persisters to start supporting this if we see enough user interest.`

Should we raise a new issue to "Assess how difficult refactoring existing sagas is" ?

[SzymonPobiega]

SQLP supports gradual change of correlation properties. It also stores version information so that you can easier modify the serialized json blob if you need. It does not, however, handle the type name changes in any way.

[mauroservienti]

Does the word refactor in this issue refer to code refactoring only? or should we also include business process refactoring such as:

• business process evolution in non-breaking way
• business process evolution in non-breaking way but needs to be retroactively applied to running sagas
• business process breaking evolution
• business process breaking and retroactive evolution

[SzymonPobiega]

Renaming sagas requires support from the persister e.g. in SqlP it might be possible while in others it is not. Moreover, the timeouts/replies include the type of the saga that requested them so renaming a saga would require a message mutator that fixes the type name on the timeout.

The first step should be to go through persisters and check if the simple usage scenarios work wrt renaming and then move to more advanced ones (timeouts/replies)