Fill in companion history events for mutable state tests (#5755)
## Why?
Execution mutable state tests only exercise the portion of logic related
to mutable state during CreateWorkflowExecution. Even though the tests
are meant to focus on mutable state, history event logic is integral
within the CreateWorkflowExecution implementation and therefore should
be exercised.
At the minimum, the execution stats pertaining to the associated history
events are no longer being dummy tested with always incrementing by 0.
Make admitted updates prevent workflow completion (#5794)
## What changed?
Make admitted updates prevent workflow completion, similar to how
"buffered" signal events prevent workflow completion.
## Why?
Product design decision: it should be possible to design workflows which
continue-as-new without the risk of losing admitted updates. Also, makes
behavior consistent with signal.
## How did you test it?
End-to-end test in PR using Go SDK.
## Potential risks
Could break workflows using update.
Fix schedule workflow to CAN after signals (#5799)
## What changed and why?
If a schedule was paused and received a large number of signals
(trigger, backfill, etc.), it wouldn't be able to continue-as-new and
history size could grow past the suggested limit.
For various reasons the main loop receives and processes signals across
iterations, with checking for CAN in between, so a wakeup due to a
signal (instead of a timer) would prevent CAN. Refactoring is hard due
to the determinism requirement, so the simplest fix is to do a second
check.
Remove misleading version numbers from features CI integration (#5713)
## What changed?
Remove misleading version numbers from features CI integration.
These are not actually used when `docker-image-artifact-name` is set,
which it always is in this workflow (if it wasn't, it wouldn't be
testing with the server built from the PR, it would use the latest
released cli dev server).
Add option to update dependencies after creating a release (#5788)
## What changed?
<!-- Describe what has changed in this PR -->
Add option to update dependencies after creating a release
## Why?
<!-- Tell your future self why have you made these changes -->
Prevent having stale dependencies.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
Fix migration back and forth local event handler (#5774)
- Fix migration back and forth usecase and add more tests
- fix lint
## What changed?
<!-- Describe what has changed in this PR -->
1. Fix a bug on handling replication back and forth case
2. Add more integration test to test the ^ scenario
## Why?
<!-- Tell your future self why have you made these changes -->
LocalGeneratedEventHandler cannot properly handle force replication
case.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Integration test
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
Feature is gated by a feature flag
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
n/a
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
no.
## What changed?
<!-- Describe what has changed in this PR -->
1. Add metrics to monitor non stream error on replication stack
2. Unify error log prefix, so when ^ alarm fired, we can easily search
log by prefix
## Why?
<!-- Tell your future self why have you made these changes -->
To better handling stream error and replication error
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
n/a
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
n/a
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
n/a
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
0483e4b...
by
Stephan Behnke <email address hidden>
Add MultiOperation frontend validation (#5745)
## What changed?
<!-- Describe what has changed in this PR -->
Added Frontend validation for MultiOperationExecution requests.
What _hasn't_ changed (yet): History validation and per-operation
Frontend validation.
## Why?
<!-- Tell your future self why have you made these changes -->
To make sure MultiOperationExecution request is valid before passing it
to History.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
