Fix stale mutable state being captured in update registry (#5753)
## What changed?
<!-- Describe what has changed in this PR -->
Use `c.MutableState` every time when possible (when it is not `nil`),
and use passed `ms` only when `c.MutableState` is `nil`, which is the
case only for `UpdateWithStart` scenario.
## Why?
<!-- Tell your future self why have you made these changes -->
To prevent using of stale mutable state passed in `ms` parameter while
creating update registry.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Existing tests and fault injection tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risks.
## 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/`? -->
No.
## 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.
Fill in companion history events for mutable state tests
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 intergral
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.
Enable FE proxying history reads to history service as default (#5736)
## Why?
The new logic to proxy all FE history read operations to the history
service has been part of release 1.23 and it is now safe (w.r.t. FE and
history services deployment ordering) as part of release 1.24 to start
deprecating the legacy code.
Log info message when effects are cancelled (#5748)
## What changed?
<!-- Describe what has changed in this PR -->
Log info message when effects are cancelled.
## Why?
<!-- Tell your future self why have you made these changes -->
To improve debugging expirience.
## 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? -->
No risks.
## 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/`? -->
No.
## 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.
3e6845b...
by
Tim Deeb-Swihart <email address hidden>
dlqv2: fix listing queues and correct docs (#5744)
## What changed?
I fixed a bug I introduced into the `dlq list` command for v2 DLQs and
corrected a typo in our DLQ docs
## Why?
Listing v2 DLQs panics since my protobuf changes, which means we don't
have any automated tests for that functionality.
## How did you test it?
I tested it against a cluster with DLQs
## What changed?
Unify two very similar implementations of event-reapply: one used when
resetting, and the other used during history event replication conflict
resolution.
## Why?
The duplication risked introducing bugs and made the codebase harder to
understand and maintain.
## What changed?
Enable streaming replication by default.
## Why?
<!-- Tell your future self why have you made these changes -->
## How did you test it?
Tested locally.
## 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) -->
