Dynamic config to suppress error when setting system search attributes (#5561)
## What changed?
<!-- Describe what has changed in this PR -->
Dynamic config to suppress error when setting system search attributes
## Why?
<!-- Tell your future self why have you made these changes -->
Create a way to prevent errors when new system search attributes are
added, but there is already a custom search attribute registered with
the same name.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added unit test.
## 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) -->
## What changed?
<!-- Describe what has changed in this PR -->
1. Fix stream_sender to return Stream error when there is error on
stream
2. Avoid infinite retry on stream event loop wrapper
## Why?
<!-- Tell your future self why have you made these changes -->
1. stream_sender's send/recv error is not properly wrapped, so the
eventloop wrapper is retrying infinitely on the "rpc error"
2. Avoid the infinitely retry
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Unit test
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risk.
## 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) -->
Should only affecting 1.24.
Fix parse ExecutionDuration value as quoted integer (#5555)
## What changed?
<!-- Describe what has changed in this PR -->
Fix parse ExecutionDuration value as quoted integer.
## Why?
<!-- Tell your future self why have you made these changes -->
It used to work when querying `ExecutionDuration='123'`.
## 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) -->
## Why?
<!-- Tell your future self why have you made these changes -->
## 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) -->
## What changed?
<!-- Describe what has changed in this PR -->
Fix parse duration error type to be a ConverterError.
## Why?
<!-- Tell your future self why have you made these changes -->
If the parsing failed, it's an issue with user input, not an internal
error.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added tests to make sure errors returned by this function is always a
ConverterError.
## 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 execution duration calculation in Visibility (#5504)
## What changed?
<!-- Describe what has changed in this PR -->
Fix execution duration calculation in Visibility
## Why?
<!-- Tell your future self why have you made these changes -->
PR #4961 changed the definition of execution duration by accident.
## 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) -->
## 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) -->
## What changed?
Validate normal TQ on sticky poll
## Why?
On sticky poll, we fetch normal TQ's UserData. So an invalid normal TQ
on a sticky queue would still trigger a load for the invalid normal
queue.
## How did you test it?
Manual test with invalid TQ.
## 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) -->
## What changed?
Add string validation for a few string fields
## Why?
Since we disable utf8 string validation from proto level, we want to
enforce minimal validation for some key fields.
## How did you test it?
Unit tests
## Potential risks
No
## 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) -->