Add revision number mechanics for child and CAN workflows #8632

Shivs11 · 2025-11-13T14:37:51Z

What changed?

Add revision number mechanics for child workflows and CAN workflows.
Additionally, this PR introduces the following change conceptually: Child workflows of AutoUpgrade parents and CAN workflow executions of AutoUpgrade workflows have their first task as AutoUpgrade by default. Previously, it was unversioned.

Why?

Resolving eventual consistency issues.

How did you test it?

Potential risks

None since this feature is gated by a dc

Note

Adds inherited_auto_upgrade_info propagation and revision-number-based dispatch so child and continue-as-new workflows start with AutoUpgrade behavior when appropriate; updates matching/history logic and tests.

API/Proto:
- Add StartWorkflowExecutionRequest.inherited_auto_upgrade_info (and getter) to carry deployment version and revision from parent/previous run.
History Service:
- Populate/propagate InheritedAutoUpgradeInfo when starting child workflows and during ContinueAsNew; avoid when pinned inheritance applies or namespaces differ.
- On start, set execution VersioningInfo (deployment, behavior AutoUpgrade) and revision number from inherited info.
- Minor fixes: use request context for version checks; guard SetVersioningRevisionNumber against nil.
Matching:
- Add test hook MatchingIgnoreRoutingConfigRevisionCheck and allow bypassing routing-config revision gate in updates.
- Minor cleanup in partition manager; keep revision-based queue selection logic.
Tests:
- Add/rename functional tests covering child/CAN inheritance, cross-TQ behavior, retry no-bounce with revision lag, and propagation helpers; introduce rollback utility for task queue user data.
Deps:
- Bump go.temporal.io/api to latest prerelease.

^{Written by Cursor Bugbot for commit 8a342ab. This will update automatically on new commits. Configure here.}

tests/versioning_3_test.go

common/util.go

service/history/workflow/mutable_state_impl.go

service/history/workflow/retry.go

service/history/workflow/mutable_state_impl.go

service/matching/task_queue_partition_manager.go

tests/versioning_3_test.go

service/matching/matching_engine.go

Shivs11 · 2025-11-25T16:00:57Z

chasm/tree_test.go


-	subComponent1, err := testComponent.SubComponent1.Get(chasmContext)
-	s.NoError(err)
+	subComponent1 := testComponent.SubComponent1.Get(chasmContext)


[for reviewer]: ignore this as I have another PR open.
#8699

service/history/workflow/retry.go

ShahabT · 2025-11-25T19:25:30Z

tests/versioning_3_test.go

 	useRevisionNumbers        bool
-	// TODO: this is always false. clean it up.
-	useNewDeploymentData bool
+	useNewDeploymentData      bool


these two always have same values, we should just use one var. IMO useRevisionNumbers describes the flag better.

Yes. Sorry, I should have kept a comment there but basically, after this PR goes in, I am sending another one which will just deal with versioning_3_test refactors.

That PR shall remove this variable completely and replace wherever we are using this with useRevisionNumbers.

I didn't wanna clutter this PR since it's anyways kinda big and is making some fundamental changes.

ShahabT · 2025-11-25T19:26:32Z

tests/versioning_3_test.go

 	})

-	t.Run("async_deployment", func(t *testing.T) {
+	t.Run("async_new_deployment_data", func(t *testing.T) {


Nit: async comes with new deployment data anyway so not sure if we need to mention it I tried to avoid making test names so long.

ShahabT · 2025-11-25T19:29:49Z

tests/versioning_3_test.go

 }

+// TODO (Shivam): I think one may need to slightly modify this now that we are actually "inheriting" the autoupgrade version.
 func (s *Versioning3Suite) TestWorkflowRetry_Unpinned_ExpectNoInherit() {


Yup, if the logic is changing in this PR, shouldn't we update the test at the same time? otherwise, it'd fail, right?

sorry, that comment is misleading imo - what i meant to add there was change the name of this test since we are inheriting the version from the parent!!

What this test is testing will still pass with my changes. The reason being as follows:

This test is testing that a retry of an autoUpgrade workflow bounces "ahead" to the next current deployment version of the task-queue. This, in theory, shall also work with my changes since the retried workflow shall inherit the revision number (and deployment version) prior to the retry, but will always be scheduled on the current deployment version if it is more recent (in this case it will be since we wait for tv2 to be current prior to kickstarting the retry)

Shivs11 · 2025-11-25T21:29:38Z

tests/versioning_3_test.go

 }

-// Fallback of revision number mechanics: Independent activities are eventually consistent.
-func (s *Versioning3Suite) TestActivityTQLags_IndependentActivityDispatchesToItsCurrentDeployment() {


no point in having this imho

This is something that revision numbers cannot solve. It didn't make sense to have a test for something for revision numbers where it's a limitation and also this is not something which we wanna solve in the near future either. I think it was decided to let customers know that while running indepedant activities, one could expect some bouncing of tasks so it is important to keep activity defs compatible

ShahabT

Can we get @carlydf approval for history side? she's more familiar with this part and also this is related to trampolining.

carlydf

Left some comments. I think a good chunk of repeated test code can be avoided if we just wait for propagation from inside the setCurrent helper function.

Also, I wonder if TestChildStartsWithParentRevision_SameTQ_TQLags, TestChildStartsWithNoInheritedAutoUpgradeInfo_CrossTQ, and TestChildStartsWithParentRevision_SameTQ_TQAhead could share more code. If it ends up being flaky or we want to fix the test, it's nice to only have to fix code in one place

service/history/workflow/mutable_state_impl.go

service/history/workflow/retry.go

service/matching/matching_engine.go

tests/worker_deployment_test.go

tests/versioning_3_test.go

carlydf · 2025-11-26T20:08:27Z

tests/versioning_3_test.go

 }

-// Fallback of revision number mechanics: Independent activities are eventually consistent.
-func (s *Versioning3Suite) TestActivityTQLags_IndependentActivityDispatchesToItsCurrentDeployment() {


carlydf · 2025-11-26T20:09:59Z

tests/versioning_3_test.go

+		return resp.GetWorkerDeploymentInfo().GetRoutingConfigUpdateState() == enumspb.ROUTING_CONFIG_UPDATE_STATE_COMPLETED
 	}, 10*time.Second, 100*time.Millisecond)

-	// Update the userData for the workflow TQ *only* by setting the current version to v1


wait im confused, doesn't removing this completely change the test?

I think the diff is misleading!
This is comparing the diff line by line, and on these lines stood the test TestActivityTQLags_IndependentActivityDispatchesToItsCurrentDeployment which I am removing in this PR.

The diff you are seeing here is just showing the outdated test's content. This test that I am adding is brand new.

proto/internal/temporal/server/api/historyservice/v1/request_response.proto

carlydf

redundant propagation checks

tests/versioning_3_test.go

carlydf · 2025-11-26T21:10:43Z

tests/versioning_3_test.go

 		Status: enumspb.WORKER_DEPLOYMENT_VERSION_STATUS_CURRENT,
 	}}, []string{}, tqTypeWf, tqTypeAct)

 	// Wait until all task queue partitions know that v1 is current.


do you mean to comment this out?

this test is gonna undergo some changes so these changes can be ignored.

tests/versioning_3_test.go

service/history/transfer_queue_active_task_executor.go

tests/versioning_3_test.go

Shivs11 added 8 commits November 12, 2025 09:59

[draft]

2e678d7

[draft]

acc0596

draft for child completed

fdc4a5e

Merge branch 'main' into ss/revision-number-for-child-CAN

c1b214b

add auto-upgrade bouncing test

f6bceda

remove non-required changes by claude which were making tests fail

bdb93a5

refactor a functional test to prevent flakiness

2a381f8

continue-as-new mechanics

0cf7412

Shivs11 changed the title ~~Add revision number mechanics for child~~ Add revision number mechanics for child and CAN workflows Nov 13, 2025

Shivs11 added 4 commits November 13, 2025 12:20

remove the MS checks from the tests (for now)

426c051

attempt to reduce flaky test

9904473

run make proto again

929da9b

skip the unversioned bouncing test since it's flaky (for now)

fbe0349

Shivs11 commented Nov 13, 2025

View reviewed changes

tests/versioning_3_test.go Show resolved Hide resolved

remove non-required comments

45bc0b9

Shivs11 marked this pull request as ready for review November 14, 2025 03:46

Shivs11 requested review from a team as code owners November 14, 2025 03:46

cursor bot reviewed Nov 14, 2025

View reviewed changes

common/util.go Outdated Show resolved Hide resolved

Shivs11 commented Nov 14, 2025

View reviewed changes

common/util.go Show resolved Hide resolved

[failing test due to dc changes/switches]

4e59e2b

cursor bot reviewed Nov 20, 2025

View reviewed changes

service/history/workflow/mutable_state_impl.go Outdated Show resolved Hide resolved

service/history/workflow/mutable_state_impl.go Show resolved Hide resolved

service/history/workflow/retry.go Outdated Show resolved Hide resolved

Shivs11 added 2 commits November 20, 2025 14:07

current

a88873a

working tests

be0d632

cursor bot reviewed Nov 20, 2025

View reviewed changes

service/history/workflow/mutable_state_impl.go Show resolved Hide resolved

service/matching/task_queue_partition_manager.go Outdated Show resolved Hide resolved

Merge branch 'main' into ss/revision-number-for-child-CAN

50edf80

cursor bot reviewed Nov 21, 2025

View reviewed changes

tests/versioning_3_test.go Outdated Show resolved Hide resolved

Shivs11 added 3 commits November 20, 2025 20:49

add errors package

a6e3066

all tests for child, retry and CAN work

8f45e75

nice helper function for rolling back task-queue userData

8b3072c

Shivs11 commented Nov 25, 2025

View reviewed changes

service/matching/matching_engine.go Show resolved Hide resolved

some final (hopefully) cleanups

af2f964

Shivs11 commented Nov 25, 2025

View reviewed changes

validation to not allow both inheritedPinned and inheritedAU to be set

0bd3580

cursor bot reviewed Nov 25, 2025

View reviewed changes

service/history/workflow/retry.go Show resolved Hide resolved

Shivs11 added 2 commits November 25, 2025 11:46

regenerate protos

7686f08

Merge branch 'main' into ss/revision-number-for-child-CAN

487863c

Shivs11 mentioned this pull request Nov 25, 2025

[Worker Versioning GA]: Add autoUpgrade information inside of events temporalio/api#665

Merged

ShahabT reviewed Nov 25, 2025

View reviewed changes

update test name and some minor comments

a7f242f

Shivs11 commented Nov 25, 2025

View reviewed changes

ShahabT reviewed Nov 25, 2025

View reviewed changes

carlydf reviewed Nov 26, 2025

View reviewed changes

proto/internal/temporal/server/api/historyservice/v1/request_response.proto Outdated Show resolved Hide resolved

carlydf reviewed Nov 26, 2025

View reviewed changes

Shivs11 added 4 commits November 26, 2025 18:17

address all comments

6da4ae7

update go.mod and regenerate protos

bfa60b8

make a nice helper for propagation wait

a5657c8

protos

c5c28ee

carlydf approved these changes Nov 26, 2025

View reviewed changes

cursor bot reviewed Nov 26, 2025

View reviewed changes

service/history/transfer_queue_active_task_executor.go Outdated Show resolved Hide resolved

Shivs11 and others added 3 commits November 26, 2025 18:59

safeguard for only filling in the autoupgrade info if it's non-nil

7a0a876

Merge branch 'main' into ss/revision-number-for-child-CAN

8118b85

Merge branch 'main' into ss/revision-number-for-child-CAN

8a342ab

cursor bot reviewed Nov 27, 2025

View reviewed changes

tests/versioning_3_test.go Show resolved Hide resolved

Shivs11 enabled auto-merge (squash) November 27, 2025 02:20

Shivs11 merged commit ada80b8 into main Nov 27, 2025
96 of 98 checks passed

Shivs11 deleted the ss/revision-number-for-child-CAN branch November 27, 2025 02:41

Add revision number mechanics for child and CAN workflows #8632

Add revision number mechanics for child and CAN workflows #8632

Uh oh!

Conversation

Shivs11 commented Nov 13, 2025 • edited by cursor bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

Why?

How did you test it?

Potential risks

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShahabT left a comment

Choose a reason for hiding this comment

Uh oh!

carlydf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

carlydf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Shivs11 commented Nov 13, 2025 •

edited by cursor bot

Loading