mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-04 02:04:03 +00:00
## What changed?
<!-- Describe what has changed in this PR -->
This is the history side changes needed for the Worker Versioning
Assignment Rules to work. It includes:
- add versioning stamp to task started events based on the poller
- persisting the assigned build IDs in mutable state for new workflows
and independently-versioned activities. This is done in two places:
- when build ID is returned by matching as an output of Add*Task API
- from the versioning stamp in task started events to cover the
following cases:
- Sync-match
- MS rebuild based on history events
- When we failed to update build ID at schedule time
- Matching does not re-evaluate the version directive for spooled tasks
for WV2, instead it uses the assignment decision made at spool time
(which is the build ID of the physical task queue in which the task was
spooled to).
## Why?
<!-- Tell your future self why have you made these changes -->
Part of Worker Versioning new API.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added unit test and functional tests where needed.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
One database write is added if all the following conditions are true for
a workflow task:
- assignment rules are added for the Task Queue (i.e. worker versioning
is enabled)
- sync-match did not happen for this task
- this is the first workflow task of the execution
- the workflow has not inherited a build ID (for child WF or CaN)
One database write is added if all the following conditions are true for
an activity task:
- assignment rules are added for the Task Queue (i.e. worker versioning
is enabled)
- sync-match did not happen for this task
- the activity is on a different task queue (or otherwise asked to be
independently assigned to a build ID)
## 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/`? -->
None so far.
## 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