Skip to content

Releases: indeedeng/iwf

v1.15.1

16 Dec 22:19
8fffb80
Compare
Choose a tag to compare

What's Changed

New Contributors

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

v1.15.0

10 Dec 19:45
1bed2dc
Compare
Choose a tag to compare

What's Changed

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

v1.14.1

02 Dec 19:44
1d24724
Compare
Choose a tag to compare

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

22 Nov 22:38
425478b
Compare
Choose a tag to compare

What's Changed

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

v1.13.0

20 Nov 10:21
95bd316
Compare
Choose a tag to compare

New feature

  • New framework for emitting workflow events

What's Changed

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

v1.12.0

05 Nov 16:08
7fe9eb9
Compare
Choose a tag to compare

What's Changed

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

v1.11.1

01 Nov 22:29
bcb1d8c
Compare
Choose a tag to compare

What's Changed

New Contributors

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

v1.11.0

21 Oct 18:08
767a927
Compare
Choose a tag to compare

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

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

v1.10.1

04 Oct 13:18
5b4cefb
Compare
Choose a tag to compare

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

v1.10.0

30 Sep 21:21
e0c4caa
Compare
Choose a tag to compare

Highlights

  • Renamed IdReusePolicy from ALLOW_IF_PREVIOUS_EXISTS_ABNORMALLY to ALLOW_IF_PREVIOUS_EXITS_ABNORMALLY; required for backward compatibility in SDKs
  • Renamed GetDataObjects to GetDataAttributes in Temporal and Cadence queryHandler

New features

  • Support initial data attributes when starting workflow

What's Changed

New Contributors

Full Changelog: v1.9.2...v1.10.0