## 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) -->
Since we disable utf8 string validation from proto level, we want to
enforce minimal validation for some key fields.
Unit tests
No
<!-- 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) -->
Skip verifying workflow which has already passed retention time (#4770)
<!-- Describe what has changed in this PR -->
**What changed?**
Previous logic skip workflow of which retention is within a range of
current time. But we actually just need to skip workflow already passed
retention time.
<!-- Tell your future self why have you made these changes -->
**Why?**
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
524bda3...
by
Michael Snowden <email address hidden>
Fix bug causing duplicates when listing s3-archived workflows (#4712)
<!-- Describe what has changed in this PR -->
**What changed?**
We now only return one record per workflow execution when listing
archived workflows with the S3 storage backend.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
I modified our unit test to verify that we don't return any duplicates.
The previous unit test was actually too permissive and allowed
duplicates. I also manually verified this by restarting the server.
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
The ability to list archived workflows when using S3 is already very
new, as it was completely unsupported before, and the changes here are
just isolated to that query path, so there is little to lose even if
this just crashes.
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
Should update the issue when this lands.
Continue replication verification by skipping workflow which should be or soon to be deleted (#4734)
<!-- Describe what has changed in this PR -->
**What changed?**
Source and target cluster handles workflow retention separately. For a
workflow which is abort to be deleted,
it may be already deleted on target cluster but still exist on source,
which cause verification delay.
We skip workflow of which retention time is close to current time to
continue the verification.
<!-- Tell your future self why have you made these changes -->
**Why?**
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
