6a8e63e...
by
Carly de Frondeville <email address hidden>
Merge branch 'main' into cdf/minor-test-nit
e1d19a5...
by
Carly de Frondeville <email address hidden>
minor improvements to version rule unit tests
75c25bc...
by
Carly de Frondeville <email address hidden>
Apply the visibility rate limit to DescribeTaskQueue (#5730)
## What changed?
Apply the visibility rate limit to DescribeTaskQueue
## Why?
Because `DescribeTaskQueue` relies on visibility (when
`api_mode==ENHANCED` and `ReportTaskReachability==true`).
## How did you test it?
Functional test. When the new line in `quotas.go` is not there, the test
fails, when it is there, the test succeeds.
## Potential risks
This might be overly restrictive to other non-visibility uses of
`DescribeTaskQueue`. In the future we could rate limit only the calls to
visibility by calling `matching --> frontend -->
CountWorkflowExecutions` instead of `matching --> visibilityManager -->
CountWorkflowExecutions`, but this is sufficient to protect visibility
from high reachability load for now and we can optimize after the
pre-release.
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.
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) -->
