Recommended activity versioning logic

Community Support
1

We have one workflow and one activity that got changed as follows.

Initial version:

type FooWorkflowParams struct {
	printFoo bool
}

FooWorkflow(params *FooWorkflowParams) {
	workflow.ExecuteActivity(FooActivity, FooActivityParams{printFoo: params.printFoo})
}

type FooActivityParams struct {
	printFoo bool
}

FooActivity(params *FooActivityParams) {
	if params.printFoo {
		fmt.Println("foo")
	}
}

Updated version (Adds the ability to print Bar)

type FooWorkflowParams struct {
	printFoo bool
	printBar bool
}

FooWorkflow(params *FooWorkflowParams) {
	workflow.ExecuteActivity(FooActivity, FooActivityParams{printFoo: params.printFoo, printBar: params.printBar})
}

type FooActivityParams struct {
	printFoo bool
	printBar bool
}

FooActivity(params *FooActivityParams) {
	if params.printFoo {
		fmt.Println("foo")
	}

	if params.printBar {
		fmt.Println("bar")
	}
}

Suppose there are two workers(both having the capability to run the workflow and activity) and only one of the worker W1 got upgraded with the new versions but not W2. Now, if the W1 handles a new workflow request and the activity fired by this workflow lands on W2 which is not yet upgraded, what’s the recommended way to make sure that W2 doesn’t handle this activity? Creating a new activity name every time the activity is updated and registering all the older and newer activities doesn’t appear to be a clean way of writing and maintaining the code.

Given that workflow is setting ‘printBar’, it assumes that ‘bar’ is printed and it’s important that ‘bar’ is actually printed.

2

I would fail the activity and let it retry. As deployment is not long running the errors will go away after it is complete.

3
  1. Given that the first version of the activity is already running on the worker, how will the activity fail? Is there any temporal construct that’s available?
  2. If we were to write the first version of the activity today, how do we write it in such a way that it’ll fail? Is there something like GetVersion call for activity similar to what we have for the workflow?
4
  1. If it is running on the worker, it will keep running unless the worker is brought down. When it is brought down then the activity will timeout after the StartToClose timeout and be retried on a different worker.
  2. I recommend implementing activities in a way that they are backward and forward-compatible. For noncompatible changes, I recommend changing their name.
1 Like