Fix deleting namespaces with only workflows in other division (#5760)
## What changed?
Followup to #5343, which didn't account for the situation where a
namespace has no workflows in the default namespace division, but has
some in another namespace division: The reclaim resources workflow first
does a Count of workflows before it does List and deletes what it finds.
The List was updated to search all divisions, but the initial Count was
not.
## Why?
Correctly delete namespaces in all cases
## How did you test it?
updated unit test, searched for all visibility manager calls and ensure
they have a Query
Do not retry namespace level resource exhausted error in service clients (#5757)
<!-- Describe what has changed in this PR -->
- Do not retry namespace level resource exhausted error in service
clients
<!-- Tell your future self why have you made these changes -->
- Backoff & retry will increase API latency and trigger alerts.
- Namespace level resource exhausted error even if returned won't count
against SLA.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Unit test
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
<!-- 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 this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
- Yes.
## What changed?
Use correct deprecated metrics for per-command metrics.
## Why?
This was broken in #5435, the deprecated metrics were collapsed to the
new CommandCounter metric, but that double-counts them and makes labels
inconsistent.
7e5bcc9...
by
Stephan Behnke <email address hidden>
WorkflowIdConflictPolicy default on History (#5701)
## What changed?
<!-- Describe what has changed in this PR -->
Set default for `WorkflowIdConflictPolicy` in History as well.
## Why?
<!-- Tell your future self why have you made these changes -->
An issue can happen on downgrade where the Frontend is running a
previous version that doesn't set the default but the newer History
expects it.
## How did you test it?
Tested locally by commenting out the code in Frontend and History;
ensuring it fails and then re-enabling the code in History to verify it
fixes it.
## Potential risks
None; if there is a policy already, nothing happens.
## 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) -->
Activate schedule workflow changes in #5179, #5277, #5344, and #5381 (#5698)
## What changed?
Activate schedule workflow logic changes. Some of this code is not in
1.23.0, but we can patch those PRs into 1.23.1 to support downgrades to
the 1.23 series.
## Why?
Fix bugs, support new features, make more efficient.
## How did you test it?
existing tests (on those PRs)
