Releases: indeedeng/iwf
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
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:
- Stop all the RPC locking usage
- 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_TriggerContinueAsNew
is needed for this signal. - Upgrade iWF server to the new version
- Trigger another continueAsNew to all the running workflows again(so that they will use the new global version)
- 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:
- deploy the new version code, which will be using "old" for both "SignalWithStartOn" and "WaitForOn". Nothing changed at this point.
- 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.
- 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.
- 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.
- 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
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
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
- Rename GetDataObjects to GetDataAttributes by @longquanzheng in #418
- Update to latest IDL (add waitForKey and make commandId optional) by @longquanzheng in #420
- Add commandId back as required field in commandResults for SDK backward compatibility by @longquanzheng in #422
- Add default start argument to main func by @lwolczynski in #421
- IWF-103: Require every commandId to exist for ANY_COMMAND_COMBINATION_COMPLETED by @lwolczynski in #423
- Add check for cron workflow using temporal schedule by @longquanzheng in #426
- IWF-125: Limit error size return from API by @lwolczynski in #429
- Fix Cadence pipeline checks not starting by @samuel27m in #431
- IWF-106: Fix typo IdReusePolicy of ALLOW_IF_PREVIOUS_EXISTS_ABNORMALLY by @stevo89519 in #430
- IWF-118: Refactor package structure by @longquanzheng in #433
- IWF-136: Support initial data attributes when starting workflow by @lwolczynski in #435
New Contributors
- @lwolczynski made their first contribution in #421
- @samuel27m made their first contribution in #431
- @stevo89519 made their first contribution in #430
Full Changelog: v1.9.2...v1.10.0
v1.9.2 Patch Release
What's Changed
- fix temporal command line arguments by @something-something-something in #399
- Support WaitForCompletionStateIds and add local activity input debug by @longquanzheng in #407
New Contributors
- @something-something-something made their first contribution in #399
Full Changelog: v1.9.1...v1.9.2
v1.9.1 Patch Release
What's Changed
- Allow omit rpc input/output for optimization by @longquanzheng in #390
- Support local activity optimization by @longquanzheng in #389
- Use omit empty for ExecuteRpcSignalRequest model by @longquanzheng in #392
- Use timer duration to replace firingTimestamp for timerCommand by @longquanzheng in #393
- Add local activity test and truncate unnecessary error response by @longquanzheng in #395
Full Changelog: v1.9.0...v1.9.1
v1.9.0 Release
What's Changed
- use omitempty for start workflow input by @longquanzheng in #370
- Optimize versioning actions by sending via request by @longquanzheng in #368
- Fix NDE for setting version at start by @longquanzheng in #374
- pin openapi-generator-cli to 6.6.0 by @duoertai in #375
- Add start delay in workflow start options by @duoertai in #376
- add start delay integration test by @duoertai in #377
- Add detailed fields for error logs in api service by @longquanzheng in #380
- Rename versioning optimization flag by @longquanzheng in #382
- Support ALL_WITH_PARTIAL_LOCK by @longquanzheng in #383
- Fix bug for LOAD_ALL_WITH_PARTIAL_LOCK by @longquanzheng in #384
- Support trigger continueAsNew API by @longquanzheng in #385
Full Changelog: v1.8.3...v1.9.0
v1.8.3 Patch Release
What's Changed
- Fix/improve waitForStateCompletion error handling by @longquanzheng in #363
Full Changelog: v1.8.2...v1.8.3
v1.8.2 Release
Highlights
Cron is deprecated in Temporal.
- There are issues with cron like continue as new will lose the cron schedule: https://community.temporal.io/t/temporal-cron-questions/201/3
- Also the execution timeout cannot be set correctly.
As a result it's now replaced with Schedule.
What's Changed
- Default to continueAsNew with disable sys search attributes by @longquanzheng in #357
- Fix broken integ test assertion for workflowConfig by @longquanzheng in #358
- Replace cron with temporal schedule by @longquanzheng in #361
Full Changelog: v1.8.1...v1.8.2