Versioning/Patching when using DSL

Community Support
, ,
1

Hi,

I have a few questions when using DSL to drive workflows. In Temporal, we will have a single workflow that accepts the DSL as input and executes accordingly.

When thinking about versioning and patching workflows in context of DSL, I wanted to clarify a couple of points.

New version of “Activity”

  • If you have updated Activity code, any running workflows yet to execute the activity code will use the newer code?
  • What about replays?
  • If we wanted to introduce versioning of Activity, how can we achieve this? Would you add some some naming convention to activity names - e.g.
func ActivityV1(ctx context.Context, name string) (string, error) {
	logger := activity.GetLogger(ctx)
	logger.Info("Activity", "name", name)
	return "Hello " + name + "!", nil
}

Update DSL

  • If you’ve updated your DSL, then default behaviour will be that any new workflow instantiation will use the updated DSL
  • If you have running workflows on old DSL, can we update them to use the newer DSL?
  • Could we use a signal to update the DSL?
  • Any disadvantages ?

Thank you,
Jay.

2
  • If you have updated Activity code, any running workflows yet to execute the activity code will use the newer code?

You can update your activity code without breaking workflow determinism (dont need to version)

  • What about replays?

during history replay your worker is going to use the recorded activity results of already executed activities and won’t re-execute them again

  • If you’ve updated your DSL, then default behaviour will be that any new workflow instantiation will use the updated DSL

I assume that your dsl defines the orchestration logic and your workflow code reads it and then uses temporal apis according to instructions in dsl, so my guess here is yes

  • If you have running workflows on old DSL, can we update them to use the newer DSL?

Think depends on what old/new means, your workflow code would need to be updated if the dsl parsing needs to update. the parsing should be able to be able to handle both old and new dsl structure.
you mentioned you pass the dsl as workflow data input, so each workflow instance you create would execute instructions passed to it

  • Could we use a signal to update the DSL?

Can you give more info? So you want to start executing instructions from dsl passed in as workflow input and at some point continue execution of new instructions passed in signal payload? I think this should be ok as you are not changing the past.

3

I would add to Tihomir’s answer that you have to define yourself the semantics of updating the DSL. How do you know that a DSL update is backward compatible? If you know how to apply the state of your workflow that was generated by the old DSL to the new DSL then using signal is the way to go.

4

Thanks @tihomir, @maxim

To clarify some points.

So the topic here is the actual DSL, which as you rightly guessed, defines the orchestration logic. In my example, the DSL has been updated.

I understand how the versioning of Temporal Workflow function works and happy with it’s logic.

So some great points here and this is something we need to define further. However, under normal circumstances, we expect to version the DSL and any drastic, non-backwards compatible changes should result in a new version, new instances of the DSL will use the newer version.

The need to update running workflows will be limited to circumstances where there is a critical bug that needs patching. I wanted to verify if a signal can be used inject an updated DSL. In most cases, it would be the activity code that will require updates and we should be good, but if the DSL also requires an update (e.g. adding in a new activity/branch), it’s good to know we can use a signal.