Trampolining Part 2: Avoid infinite loops for Pinned workflows by Shivs11 · Pull Request #9374 · temporalio/temporal

Shivs11 · 2026-02-20T18:02:36Z

What changed?

Consists of the change to prevent any Pinned workflows, that may have forgotten to have the initial CAN Behaviour as AU, from CAN'ing infinitely.
Also allows trampolining of a Pinned workflow onto the Unversioned if un-versioned is the current version of the worker deployment at that point in time. Note, the effective behaviour of the workflow would later then be unversioned.

Why?

Worker-Versioning correctness.

How did you test it?

Potential risks

Pre-existing workflows (started before this fix) have nil TargetVersionOnStart. On the first WFT after deployment, "" !=
"build-v2" → spurious targetDeploymentVersionChanged=true. This is a one-time false-positive regression for those Pinned workflows.

Note

Medium Risk
Touches generated protobuf APIs used across internal services; while changes are mostly additive/regeneration, wire/type mismatches or partial rollouts could cause compatibility issues.

Overview
Adds a new declined_target_version_upgrade field to StartWorkflowExecutionRequest (historyservice API) so continue-as-new/retry runs can persist the prior run’s implicitly-declined target deployment version.

Regenerates protobuf Go bindings, updating import aliases/types across request_response.pb.go, and adds missing Marshal/Unmarshal/Size/Equal helpers for persistence message LastNotifiedTargetVersion.

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

service/history/workflow/workflow_task_state_machine.go

go.mod

service/history/interfaces/workflow_task_info.go

service/history/workflow/workflow_task_state_machine.go

Shivs11 · 2026-02-20T21:12:03Z

In theory, this PR could have been quite small if I had not worried/thought about the replication side of things. I think it's important to note that if we don't persist this information in history (on the event side of things), then it becomes difficult for us to rebuild the mutable state when looking at just the events. This could also cause a workflow, on a MS that has been rebuilt, to undergo an additional CAN.

one could say that this is an overkill for something which is anyways the user's fault, but my knowledge on replication and how consistent things have to be kept is quite minimal, so I decided to take a stab at this.

service/history/workflow/workflow_task_state_machine.go

Co-Authored-By: Claude Opus 4.6 <[email protected]>

# Conflicts: # api/historyservice/v1/request_response.pb.go

Co-Authored-By: Claude Opus 4.6 <[email protected]>

go.mod

Co-Authored-By: Claude Opus 4.6 <[email protected]>

service/history/workflow/workflow_task_state_machine.go

carlydf · 2026-03-11T02:35:00Z

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

    // subsequent workflow tasks.
    temporal.api.deployment.v1.InheritedAutoUpgradeInfo inherited_auto_upgrade_info = 16;
+    // The previous run's latest target Worker Deployment Version. Passed through
+    // during continue-as-new to be written on the WorkflowExecutionStartedEvent.


Nit: maybe also say "nil if this workflow is not initiated by continue-as-new"

carlydf · 2026-03-11T02:37:42Z

proto/internal/temporal/server/api/persistence/v1/executions.proto

+    // True when this run was initiated by continue-as-new or retry and inherited
+    // a pinned version from the previous run. Used in the
+    // targetDeploymentVersionChanged condition to detect continuation runs that
+    // declined upgrade.
+    bool has_inherited_pinned_version_continue_as_new_or_retry = 114;


why are you including retry?

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

service/history/workflow/mutable_state_impl.go

service/history/workflow/workflow_task_state_machine.go

service/history/workflow/mutable_state_impl.go

# Conflicts: # go.mod

…ides

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

service/history/workflow/workflow_task_state_machine.go

service/history/workflow/mutable_state_impl.go

# Conflicts: # go.mod # go.sum

distinguish "not set" from "set to unversioned (nil)". This fixes the case where a pinned workflow transitioning to an unversioned target was not receiving targetDeploymentVersionChanged=true. Co-Authored-By: Claude Opus 4.6 <[email protected]>

Co-Authored-By: Claude Opus 4.6 <[email protected]>

ShahabT · 2026-03-12T18:15:55Z

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

    // After the first workflow task, the effective behavior of the workflow is determined by worker-sent values in
    // subsequent workflow tasks.
    temporal.api.deployment.v1.InheritedAutoUpgradeInfo inherited_auto_upgrade_info = 16;
+    // During the previous run of this workflow, if it exists, the server may have


Suggested change

// During the previous run of this workflow, if it exists, the server may have

// During the previous run of this workflow, the server may have

ShahabT · 2026-03-12T18:21:22Z

proto/internal/temporal/server/api/persistence/v1/executions.proto

+    // The last target version for which the server set targetDeploymentVersionChanged
+    // to true on a workflow task started event. Updated on each workflow task start,
+    // set only when the server decides to set the targetDeploymentVersionChanged flag
+    // to true. Also read during continue-as-new/retry to pass to the new run.


we also want to be explicit about that if the last wt started event had targetDeploymentVersionChanged=false then this value would be set to nil.

ShahabT · 2026-03-12T18:43:34Z

service/history/workflow/workflow_task_state_machine.go

+		default:
+			// Otherwise — target changed + did not decline to upgrade on CaN/retry. Signal the SDK.
 			targetDeploymentVersionChanged = true
+			m.ms.executionInfo.LastNotifiedTargetVersion = &historypb.LastNotifiedTargetVersion{


we should always unset this if targetDeploymentVersionChanged becomes false.

ShahabT · 2026-03-12T19:31:53Z

service/history/workflow/workflow_task_state_machine.go

+			m.ms.executionInfo.LastNotifiedTargetVersion = &historypb.LastNotifiedTargetVersion{
+				DeploymentVersion: targetDeploymentVersion,
+			}
+			m.ms.executionInfo.NotificationSuppressedTargetVersion = nil


run 1:

pinned to v1

then target version changes to v2

run 1 CaNs without upgrade -> declined value would be set to v2 for run 2
run 2:

pinned to v1

declined value is v2

target version changes to v1 -> no notif -> last notif value is nil

here, because target version is now different from the declined value we can reset it. we should also check the revision number.

target version changes back to v2

Q1: should we notif run 2 now about v2?

yes, to give the wf another chance to go to v2

say at this point, wf CaNs but again without upgrade

Q2: should it pass v2 as declined to run 3?

yes, because it declined upgrade duh!

ty for this; have also added the rollback test.

Shivs11 · 2026-03-12T22:58:37Z

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

    // After the first workflow task, the effective behavior of the workflow is determined by worker-sent values in
    // subsequent workflow tasks.
    temporal.api.deployment.v1.InheritedAutoUpgradeInfo inherited_auto_upgrade_info = 16;
+    // The target version that the previous run's SDK declined to upgrade to.


that the previous run implicitly declined to upgrade to.

…ned wfs (#721) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._  -WISOTT  - Users that could using trampolining in the near future could run into a problem, which shall only surface if the workflow author does not have AutoUpgrade as the initial CAN behaviour for their Pinned workflows. As of today, if a user does hit this case, they would have the pinned workflow CAN'ing infinite number of times. This is because a pinned workflow would commence on the pinned version (since it would have inherited pinned version set to true) and if the pinned version is different than a worker-deployment's current version, the targetDeploymentVersionChanged would be set to true in the server. This would then result in the workflow just CAN'ing all the time! - This change aims to change that by only allowing at-most one CAN for such pinned workflow executions, and it does so by remembering what the initial version was at the start of the continue-as-new.  **Breaking changes**  - [PR!](temporalio/temporal#9374) --------- Co-authored-by: Claude Opus 4.6 <[email protected]>

semgrep-managed-scans · 2026-03-12T23:43:56Z

Semgrep found 2 missing-explicit-permissions findings:

.github/workflows/promote-docker-image.yml
- L26-80 - Triage
- L82-122 - Triage

No explicit GITHUB_TOKEN permissions found at the workflow or job level. Add a permissions: block at the workflow root (applies to all jobs) or per job with least privilege (e.g., contents: read and only specific writes like pull-requests: write if needed).

…o trampolining-pt2

…ralio#9374) ## What changed? - Consists of the change to prevent any Pinned workflows, that may have forgotten to have the initial CAN Behaviour as AU, from CAN'ing infinitely. - Also allows trampolining of a Pinned workflow onto the Unversioned if un-versioned is the current version of the worker deployment at that point in time. Note, the effective behaviour of the workflow would later then be unversioned. ## Why? - Worker-Versioning correctness. ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [x] added new functional test(s) ## Potential risks - Pre-existing workflows (started before this fix) have nil TargetVersionOnStart. On the first WFT after deployment, "" != "build-v2" → spurious targetDeploymentVersionChanged=true. This is a one-time false-positive regression for those Pinned workflows.  --- > [!NOTE] > **Medium Risk** > Touches generated protobuf API surface used by internal services; while the change is additive, mismatched proto versions across services could cause integration/compatibility issues. > > **Overview** > Adds `declined_target_version_upgrade` to `StartWorkflowExecutionRequest` (HistoryService API) so continue-as-new/retry chains can carry forward the SDK-declined target deployment version and avoid pinned-workflow trampolining loops. > > Regenerates protobuf Go bindings, updating import/type references across `request_response.pb.go`, and adds missing `Marshal`/`Unmarshal`/`Size`/`Equal` helpers for the persistence `LastNotifiedTargetVersion` message. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 0af06d0. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>  --------- Co-authored-by: Claude Opus 4.6 <[email protected]>

Shivs11 mentioned this pull request Feb 20, 2026

Trampolining: addition of fields to remove the infinite loops for pinned wfs temporalio/api#721

Merged

Shivs11 commented Feb 20, 2026

View reviewed changes

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

Shivs11 commented Feb 20, 2026

View reviewed changes

go.mod Outdated Show resolved Hide resolved

Shivs11 commented Feb 20, 2026

View reviewed changes

service/history/interfaces/workflow_task_info.go Outdated Show resolved Hide resolved

Shivs11 commented Feb 20, 2026

View reviewed changes

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

ShahabT reviewed Feb 23, 2026

View reviewed changes

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

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

Shivs11 and others added 3 commits March 9, 2026 22:59

Addressing comments: three fields in MS and one in API

167a4a3

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Merge remote-tracking branch 'origin/main' into trampolining-pt2

11a817e

# Conflicts: # api/historyservice/v1/request_response.pb.go

Regenerate protos after merge

b426108

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Shivs11 force-pushed the trampolining-pt2 branch from 43150c7 to b426108 Compare March 10, 2026 03:02

Shivs11 marked this pull request as ready for review March 10, 2026 03:03

Shivs11 requested review from a team as code owners March 10, 2026 03:03

cursor bot reviewed Mar 10, 2026

View reviewed changes

go.mod Outdated Show resolved Hide resolved

Rename field to OrRetry and add override-removal test

4bdd8f3

Co-Authored-By: Claude Opus 4.6 <[email protected]>

cursor bot reviewed Mar 10, 2026

View reviewed changes

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

carlydf reviewed Mar 11, 2026

View reviewed changes

point to a pushed up go.mod to run the tests

551416e

cursor bot reviewed Mar 11, 2026

View reviewed changes

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

Shivs11 added 3 commits March 11, 2026 10:12

Merge remote-tracking branch 'origin/main' into trampolining-pt2

de23987

# Conflicts: # go.mod

update the test since we are always going to respect versioning-overr…

8454aaf

…ides

lint

e9aa38e

cursor bot reviewed Mar 11, 2026

View reviewed changes

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

Shivs11 added 3 commits March 11, 2026 16:17

retry of CAN + tests

56508e7

allow trampolining on unversioned version

ea8746a

lint

b5c0f67

carlydf reviewed Mar 11, 2026

View reviewed changes

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

carlydf reviewed Mar 11, 2026

View reviewed changes

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

Merge remote-tracking branch 'origin/main' into trampolining-pt2

4b5815a

# Conflicts: # go.mod # go.sum

Shivs11 and others added 4 commits March 12, 2026 09:11

fmt-imports

148fa08

Co-Authored-By: Claude Opus 4.6 <[email protected]>

add wrapper for LastNotifiedTargetVersion + test

919ea64

lint

b8e094b

ShahabT reviewed Mar 12, 2026

View reviewed changes

Shivs11 added 2 commits March 12, 2026 18:08

using the decline strategy + tests for rollback

43026e2

the annoying lint

0af06d0

Shivs11 commented Mar 12, 2026

View reviewed changes

working

bcca31a

ShahabT approved these changes Mar 12, 2026

View reviewed changes

Shivs11 and others added 2 commits March 12, 2026 19:40

remove duplicate test + update go mod

34ac162

Merge branch 'main' into trampolining-pt2

69ffc3e

Shivs11 enabled auto-merge (squash) March 12, 2026 23:41

Shivs11 and others added 3 commits March 12, 2026 19:58

proto

85e7dfc

Merge branch 'trampolining-pt2' of github.com:temporalio/temporal int…

f515d68

…o trampolining-pt2

Merge branch 'main' into trampolining-pt2

7e039eb

Shivs11 merged commit b6ae24e into main Mar 13, 2026
88 of 96 checks passed

Shivs11 deleted the trampolining-pt2 branch March 13, 2026 01:20

	// During the previous run of this workflow, if it exists, the server may have
	// During the previous run of this workflow, the server may have

Conversation

Shivs11 commented Feb 20, 2026 • 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!

Shivs11 commented Feb 20, 2026

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

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!

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!

semgrep-managed-scans bot commented Mar 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Shivs11 commented Feb 20, 2026 •

edited by cursor bot

Loading