Workflow Versioning Behavior

Community Support
, ,
1

Workflow Versioning Question #java-sdk
Workflow has code path that can be hit multiple times in its lifecycle.

I fix a bug in the workflow code path. I use the regular change versioning syntax.

I want the history of the workflow to use the older version (using Workflow.getVersion()) but use the latest version in subsequent hits of the code path for the same running workflow.

My question is whether the version tied to the workflow itself or just the history of the workflow since the change version’s introduction?

2

Calls to getVersion(String changeId, int minSupported, int maxSupported) are recorded in history as marker events. When your workflow is executed for first time (not during history replay) it returns the set maxSupported which is recorded in history. During workflow history replay the version that was recorded is used.
So versioning is tied to the history of a workflow execution. When you introduce a new change (via versioning), executions which have already completed the particular workflow code where you are introducing the change would use the recoded one. Execs that have not yet reached the part of your workflow code where you introduced the change would execute the latest version that you specify.

3

Got it!

Otherwise replay fails if there are more than 2 versions in same workflow run.

Related question is is there some provision in place to set in the stone the version of a workflow the moment it starts till its death?

This is different from the change versioning described above (which is probably used mostly for bug fixes)

Basically W1 should in entirety follow business rules B1.
W2 should in entirety follow business rules B2.

B2 can go-live before W1 ends.
Still whatever’s left of W1 should follow B1. Do we have an existing construct to satisfy this?

4

Do you have an existing construct to satisfy this?

I think at this point you are looking at business logic that you would have to bake into your workflow code for the particular workflow type.
Couple ideas that that might be useful:

  • Workflow data input
  • Signal - if you start your execution via SignalWithStart with Java sdk your signal hander is going to be invoked before your workflow method, so it could set a workflow variable that would determine which path to take
  • Visibility data - you could set different values for a search attribute in your client code when you request execution and in your workflow code you get it via Workflow.getInfo().getSearchAttributes() and make a decision based on it which path to take.

You could also look at using different task queue for B1 and B2 impls of W1 workflow type. This would require different set of workers where each has the different impl registered.

5

Thanks a lot!!!

All approaches look good.

I’m most intrigued by the different task queue solution. What inherent advantages does it have?

Is it just code cleanliness?