I am attempting to implement a change to my Activity request schema and wanted to test the backwards compatibility using replay tests in order to determine if I need to incorporate version based branching in my workflow code.
Looking at the java and go versioning documentation, it’s not always clear what changes need to be versioned with branching logic. I assumed that any change to the workflow behavior or activity req/res schema would break the deserialization of the workflow execution state.
To test such changes, I leveraged replay tests using the java test sdk (1.4), which I expected to give me relatively high confidence that my change will not be breaking the older executions of workflows.
In my current example, I am changing the type of a field on the ActivityInterface request schema, which can be serialized in the same format. For example,
String. The serialization for these two values can be the same. From what I can tell, the workflow execution state serialization does not include any type information, so I would hope that this change is backwards compatible. The replay test did not fail in this case.
To test out the replay functionality, I played around with the schema more and added/removed fields from the request and the response schemas (4 more tests for a total of 5). The only failure was a removal of a field from the activity response, which wasn’t even read in the workflow.
I could also test this out myself, but if anyone else is already aware of the expected behavior of Temporal for these cases, that would be helpful.