v1.11.0

Breaking changes for RPC locking

If you haven't used RPC locking, ignore this breaking changes.

Because there is a breaking change in Temporal SDK that could cause Non Deterministic Errors, we have introduced a version to only set temporal update handler for new versions. SetUpdateHandler is only used by RPC locking. So this will break all the production usage of the the RPC locking.

So if you are using it in production, here is how to migrate to new iWF server version:

1. Stop all the RPC locking usage
2. Trigger continueAsNew to all the running workflows, by calling the API or send the iWF system signal(you can use temporal batch signal). Only signalName __IwfSystem_TriggerContinueAsNewis needed for this signal.
3. Upgrade iWF server to the new version
4. Trigger another continueAsNew to all the running workflows again(so that they will use the new global version)
5. Enable the RPC locking again

The first continueAsNew is needed to get rid of the history that has update events. The second continueAsNew is needed so that the workflow can use a new version which allows to use the Temporal Update handler to support RPC locking.

Prepare for breaking changes for WaitForStateExecutionCompletion

NOTE: if you don't use WaitForStateExecutionCompletion or not backed by Temporal, ignore this change.

To fix the limitation in WaitForStateExecutionCompletion that doesn't work with IdReusePolicy, we will switch to use firstRunId instead workflowId when naming WaitForStateExecutionCompletion workflow in #447 . This switching will become a breaking change.

This improvement only works for Temporal because Cadence is still missing the underlying support (return firstRunId of a workflow).

To make a smooth migration, we have provided config to control the behavior. Below is the migration steps:

1. deploy the new version code, which will be using "old" for both "SignalWithStartOn" and "WaitForOn". Nothing changed at this point.
2. Change config to use "both" for "SignalWithStartOn". You will see that each State that is waited to complete, will produce two system workflows when it's completed.
3. Wait for certain time. The system workflow is meant to unblock the polling/blocking API (WaitForStateExecutionCompletion) -- "when client wait for a already completed state execution, the API should return immediately". So we can't immediately switch "WaitForOn" to "new" unless all the new ones are enough. So the waiting time will depend on your usage of this feature. If your use case will need this "unblocking" from completed state execution.
4. Change config to use "new" "WaitForOn". Rollback to "old" anytime if you regret this. At this point, "SignalWithStartOn" is still "old" so as long as you switch back, it should be okay.
5. Finally, after you are confident, use "new" for "SignalWithStartOn"

In our next release, the config value will be "new" for both "SignalWithStartOn" and "WaitForOn" as a breaking change.

Highlights

• Upgrade Temporal SDK to v1.29.1
• Add stateId and waitForKey to WorkflowWaitForStateCompletion
• Use firstRunId instead workflowId when naming WaitForStateExecutionCompletion
• Allow to use separate persistency loading policy for waitUntil

What's Changed

• Create PULL_REQUEST_TEMPLATE.md by @mixydubs in #441
• IWF-138: Add stateId and waitForKey to WorkflowWaitForStateCompletion by @lwolczynski in #440
• IWF-186: Upgrade Temporal SDK by @lwolczynski in #442
• IWF-132: Use firstRunId instead workflowId when naming WaitForStateExecutionCompletion workflow by @lwolczynski in #447
• IWF-137: Allow to use separate persistency loading policy for waitUntil by @samuel27m in #448
• IWF-207: Add new version: StartingVersionTemporal26SDK by @lwolczynski in #459

New Contributors

• @mixydubs made their first contribution in #441

Full Changelog: v1.10.1...v1.11.0