Changing Workflow Inputs

Community Support
1

Similar to:

What happens if you try to change the inputs to a workflow, like adding a new parameter? Clearly, you need to add a version check since the new parameter is used somewhere in the workflow, but what about the workflow parameter itself?

Imagine func SomeFunc(workflow.Context) becomes func SomeFunc(workflow.Context, bool). What happens during the deployment process if:

  • we still have old pods trying to execute SomeFunc(ctx), and there’s still some pods registered with that
  • and there’s some new pods with SomeFunc(ctx, bool) and other executions with SomeFunc(ctx, bool)?
1 Like
2

Adding and removing parameters at the end of the parameter list is a backwards compatible change.

I still would recommend using a single struct parameter to simplify such changes.

3

How does this work if the input is used? I assume this is covered by the case of workflow versioning?

4

The extra arguments are going to have default values. The explicit versioning of backward-incompatible changes to the workflow function is not yet supported.

5

Do you recommend using single argument structs for activities too?

6

Yes, and for their results if ever expect to change them. Activities and workflows are technically RPC and the majority of existing RPC frameworks (like gRPC) use single input and output structure for each operation.

I even wanted to make it required in Temporal. But the majority of the users voted against such proposal.

1 Like
7

Thanks for asking this question @Shannon_Tan and for the recommendation @maxim.

I think this information, including the recommendation, should belong in the temporal docs as it helps ensure critical backwards compatibility from the get-go.