Handle independent activities of unpinned workflows + more tests #6917
+232
−58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ts-act # Conflicts: # service/matching/config.go # service/worker/deployment/fx.go # tests/deployment_test.go # tests/testcore/functional_test_base.go # tests/versioning_3_test.go # tests/versioning_test.go
ShahabT
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed?
Adding a check in
RecordActivityTaskStartedto make sure the workflow TQ is present in the activity poller's deployment before starting to transition the workflow. (The check is only applicable when poller's deployment is different from the workflows effective deployment).Why?
Activities belonging to different deployments are versioned independently and should start on the current deployment of their task queues without interference with versioning of the workflow. Before this change, the workflow would be stuck in a busy loop of activity and workflow tasks, because activity started a transition to it's own deployment but then the next wf task would change the transition to it's own deployment and reschedule the activity.
How did you test it?
Added functional test.
Potential risks
None. This only affects workflows who use versioning 3. The single place in the code that is changed is within
ifblocks that can activate only when workflows/workers are using versioning 3.Documentation
Is hotfix candidate?
Yes. Ideally should be added to the release 125 because other wise workflows who use versioning 3 and also run activities belonging to TQs in other deployments will generate explosive load to server and user's workers.