v1.15.2

What's Changed

• IWF-401: update activity type name to find reset history eventID by @ktrops in #515
• IWF-124: Ignore empty output for collector by @lwolczynski in #524
• Fix Cadence starting issue in docker compose by @lwolczynski in #528

Full Changelog: v1.15.1...v1.15.2

v1.15.1

What's Changed

• IWF-415: Improve activity logging by @longquanzheng in #521
• IWF-410: emit RCP_EXECUTION_EVENT by @bowersj27 in #525

New Contributors

• @bowersj27 made their first contribution in #525

Full Changelog: v1.15.0...v1.15.1

v1.15.0

What's Changed

• IWF-369: Remove key from map when signal/internal channel is empty by @longquanzheng in #495
• IWF-385: return channel sizes for RPC by @longquanzheng in #502
• IWF-397: Avoid passing nil in WorkflowWorkerRpcRequest by @lwolczynski in #507
• IWF-372: Fix GetSearchAttributes returning nil when no IwfExecutionStateIds are set by @lwolczynski in #505
• IWF-397: Remove memo optimization for RPC by @lwolczynski in #509
• Fix continueAsNew with large snapshot(>4MB) by @longquanzheng in #482

Full Changelog: v1.14.1...v1.15.0

v1.14.1

What's Changed

IWF-335: support skipping update methods for reset by @ktrops in #486
IWF-163: Add retry policy to QueryWorkflow calls by @lwolczynski in #491

Full Changelog: v1.14.0...v1.14.1

v1.14.0

What's Changed

• IWF-141: Disable global version search attribute by @lwolczynski in #485
• NOBUG: Fix emitted metrics by @lwolczynski in #489
• IWF-364: Fix conditional complete on messages of internalChannels from state APIs by @longquanzheng in #490

Full Changelog: v1.13.0...v1.14.0

v1.13.0

New feature

• New framework for emitting workflow events

What's Changed

• IWF-122: adding set search attributes and set search objects apis by @ktrops in #476
• IWF-254: Override WorkflowConfig field by field by @lwolczynski in #478
• IWF-324: adding keyword array to search attributes by @ktrops in #479
• IWF-105: Add event logger by @lwolczynski in #480
• IWF-249: Remove optimize versioning by @longquanzheng in #484

Full Changelog: v1.12.0...v1.13.0

v1.12.0

What's Changed

• IWF-232: Add disabling sticky cache option by @lwolczynski in #473

Full Changelog: v1.11.1...v1.12.0

v1.11.1

What's Changed

• Use firstRunId for workflow context by @longquanzheng in #462
• IWF-129: Enable executingStateIds SAs for states with waitUntil by @lwolczynski in #453
• Enable logging in replay tests so that we know which event it is curr… by @longquanzheng in #464
• Update CONTRIBUTING.md to remove the brew commands that no longer needed by @longquanzheng in #463
• Update config.go to fix typo in comments by @longquanzheng in #467
• IWF-228: returning 400 for missing workflowId by @ktrops in #469
• IWF-228: skipping cadence test by @ktrops in #470
• IWF-119: Options to ignore already started error by @lwolczynski in #468
• IWF-233: Override WorkerOptions default values by @lwolczynski in #474

New Contributors

• @ktrops made their first contribution in #469

Full Changelog: v1.11.0...v1.11.1

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

v1.10.1

New Features

• Support for default HTTP Headers to be set in Interpreter Config

What's Changed

• IWF-70: allow headers to be set in Interpreter Config by @samuel27m in #424

Full Changelog: v1.10.0...v1.10.1