Use maxReadLevel to read task in source cluster when initialize replication (#5751)
## What changed?
Use current queueExclusiveHighReadWatermark to send catch up tasks when
connections between clusters are new.
## Why?
When a new pair of clusters is connected, we don't want sender to sync
all previous tasks. Only new replication tasks are needed to be synced
to receiver.
## How did you test it?
Tested locally by checking the newly added logs.
## What changed?
Add one more place where we check tasks for expiration: We already check
in taskReader when we read from persistence before adding to the buffer,
in physicalTaskQueueManager.ProcessSpooledTask after it comes out of the
buffer, and in history at record started. This adds a check after a task
comes out of a matcher, before it's passed to record started on history.
## Why?
This is intended to catch a task that expires while being blocked in the
matcher. It saves an rpc in that (rare) situation, and it also makes
some of @alexshtin 's tests more reliable.
## How did you test it?
Existing unit+functional tests. I'll try to add a new unit test
specifically for this after merging.
## What changed?
<!-- Describe what has changed in this PR -->
Update temporalio/ui docker image version
## Why?
<!-- Tell your future self why have you made these changes -->
New ui features.
## 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) -->
b13e1c6...
by
Stephan Behnke <email address hidden>
MultiOperation: set vector clock (#5802)
## What changed?
<!-- Describe what has changed in this PR -->
Setting the vector clock on any `StartWorkflowExecutionResponse` inside
the MultiOperation response.
(NOTE: there can only ever be one Start Workflow)
## Why?
<!-- Tell your future self why have you made these changes -->
Vector clock needs to be set.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
To be honest, I'm not sure how to.
## 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) -->
Make data loss check in resend history more strict (#5771)
## What changed?
Make data loss check in resend history more strict
## Why?
1. Reset workflow could send different part of workflow history and
using the same NWR.
2. For data loss case, all fields have to be equal.
## 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 -->
- Clean up some replication code
## Why?
<!-- Tell your future self why have you made these changes -->
- Clean up unused code
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Existing 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) -->
