Add one-time move to the versioning override API!

[Shivs11]

What changed?

• WISOTT

Why?

• So that operators can have a versioning override that is not sticky. The idea is that the next task of the workflow execution moves to the target version, after which the behaviour/version of the workflow are dictated by the worker response.

Breaking changes

• No, since this is a new option that I am adding whose default value is false (it's opt-in)

Server PR

• in progress

[yiminc]

so this would continue to be sticky pin behavior? I think we need to update the doc so it is more clear. It would ignore even when SDK do CAN and wants change to AU to current version?

[Shivs11]

It would ignore even when SDK do CAN and wants change to AU to current version

yes, the PinnedOverride is meant to be sticky. As long as it exists on a workflow execution, it shall be pinned to a specific workflow execution

[rkannan82]

I have given this naming some more thought. What do you think about?

• MoveAndKeepDefaultBehavior: this clearly tells the behavior. move to version X, then respect whatever is the default versioning configuration defined in code. It tells this is not sticky unlike PinnedOverride where it moves to version X and stays put.

• Also add the following to the comment:
  When you moves the wf from version x to y, and a new version z arrives.

  • if a workflow is pinned, it will stay on the y
  • if wf is auto upgrade -- it will move to z
  • if wf uses upgrade on can -- it will move to z when can happens

• Personally, I would avoid using temporary.

[Shivs11]

I quite like the model that you took when naming this, however, the only thing that bothers me is the word "Default" -- the thing is, in worker-versioning, you have two things that could be the "Default" for the true versioning behaviour of a workflow; they are:

• The workflow annotation on the workflow type
• The default workflow behaviour on the worker that is assigned to execute this workflow

When you have a versioning behaviour that is defined on the workflow type, that's the behaviour that is always followed.

Having said that, here are some of the things that came to my head the second I read your suggestion:

• What do we mean by "Default Behaviour" here? I have a feeling that an operator might could get confused thinking about which specific behaviour (workflow type annotation, worker registration) here. I worry that the word is quite overloaded here.
• I could also see a world where someone could interpret this as: "keep the old/default behavior this workflow had before the move."
• I am still inclined to using OneTimeOverride only because from the lens of an operator, it portrays the message of moving their workflows one time to a new version. While the after math of this move is subtle, I think we can rely on the operator reading the comments to have a stronger clarity

curious to hear your thoughts on this @rkannan82