When we restructure the workflow definition, what're the safe guidelines to change the activity/ function definition

Community Support
1

Hey Community,

I have a question about the deterministic errors when we restructure the activities I used in the workflow definition.

My workflow uses an activity in the first version,
fun SomeActivityX (a, b, c)
but now I wanna change it to the second version,
fun SomeActivityX(a, b, c, d=1)

  1. I am not sure how much the replay compares, does it compare entirely the original parameters to the new signature?
  2. And am I safe in directly changing the old SomeActivityX to the new one without adding version tags to it?

Background information we are building workflows in kotlin on top of java-sdk.

2

Such change doesn’t require versioning.

We recommend that production use cases use a single value type input argument. This has multiple benefits.

  • It is converted to a JSON with named properties. Positional arguments are converted to a JSON array. So their names are lost.
  • It is easier to make adding and removing properties from the value type backward compatible.
3

Thanks, Maxim, I wanna double confirm my understanding: so the change of parameter numbers doesn’t cause deterministic errors as long as the function still accepts only fun SomeActivityX(a, b, c, d=1)as default. so if I change the function to fun SomeActivityX(a, b, c, d) it will cause problem.

4

I’m confused. You asked about Java SDK. Java doesn’t support default parameter values.

5

we are using Kotlin on top of the Java-SDK. Maven Central Repository Search
so we can have something like.

image
image966×196 9.26 KB

I feel very uncertain when I reconstruct the workflow definition (workflow execution runtime data, signals, and activities are all to be modified). And I guess my uncertainty comes from I am not 100% sure about the details of the replay which I will dig into later.

And it is good to find the reply test mechanism. Also, I am thinking myself along the way if any light way can be found for a fast and more confident way of reconstruction of workflow definitions.

6

Is there any chance you could elaborate on why a change in the function signature of the would not require versioning. Is this true if it was a modification to the @WorkflowMethod?

If you have existing workflows that had been generated with the old function signature, would Temporal seamlessly be able to apply that to a new workflow signature for the same class?
Kotlin supports default parameters, but i’m not sure what it would look like at the JVM level and how that would play with Temporal

7

I don’t know Kotlin, so I cannot provide guidance here. The Temporal Java SDK allows adding and removing arguments at the end of the argument list without breaking compatibility. Parameters that a caller didn’t fill are assigned default values according to normal Java rules.

1 Like