Add one-time versioning override

[Shivs11]

Summary

• add one-time versioning override routing state
• clear one-time override after a successful WFT on the target deployment version
• carry pending one-time override through CAN, child, retry, and cron paths using existing override inheritance shape
• update server to the API-Go branch containing the new proto type

Tests

• go test -tags test_dep ./common/worker_versioning -count=1
• go test -tags test_dep ./service/history/api/updateworkflowoptions -count=1
• go test -tags test_dep ./service/history/workflow -run TestMutableStateSuite -count=1
• go test -tags test_dep ./service/history -run TestTransferQueueActiveTaskExecutorSuite -count=1

Functional tests are intentionally deferred for this draft.

---

Note

Medium Risk
Changes workflow versioning routing, override inheritance on child/CAN, and mutable-state lifecycle in history—important execution paths with broad test coverage but non-trivial edge cases (races with in-flight WFTs).

Overview
Adds one-time versioning override so operators can route the next workflow task to a target deployment version without permanently pinning the run.

A pending one-time override is treated like a temporary pin for effective deployment/behavior, search attributes, task-queue membership validation, and version reactivation signals. UpdateWorkflowExecutionOptions field masks now accept v0.32 pinned, auto_upgrade, and one_time (including nested target version fields). The override clears when a workflow task completes on the target version; completion on a different version leaves it pending.

Child workflows inherit pending one-time (and pinned) overrides when the target version owns the child task queue; Continue-as-new and reset/reapply paths are covered in tests. go.temporal.io/api is bumped for the new proto oneof.

^{Reviewed by Cursor Bugbot for commit 6d94c7b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Shivs11]

the reason why the child workflow path is receiving this special treatment but none of CAN/retry/cron paths are is because of the following idea:

• if an operator has a "Started" WFT and were to run a VersioningOverride (One Time Move) operation, and the said WFT returns a command to CAN/retry/cron, we reject those commands since we have a buffered history event thanks to that pending one time move command. Thus, for these three primitives, we shall always only have the case where the task finishes and the pending one time move is cleared, after which we handle commands (i have added versioning tests that are validating this)

• on the other hand, the child path is a bit different in the sense that we don't reject this start child command even if we do have buffered events.

[Shivs11]

this is something which i just over thought while working on this, or something we missed while we wrote update workflow options?

question: why don't we have these mask options for all the paths for api's that were added in the v0.32 phase? cc - @carlydf

have added them here, but could be totally off hence the q

[cursor]

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

^{Reviewed by Cursor Bugbot for commit 6d94c7b. Configure here.}

[cursor]

One-time override skips deployment name

Low Severity

When applying a one-time versioning override, updateVersioningOverride updates WorkerDeploymentName only inside the OverrideIsPinned branch. One-time overrides are not pinned in that sense, so executionInfo.WorkerDeploymentName can stay on the pre-override deployment until a later workflow task completion refreshes it.

 

^{Reviewed by Cursor Bugbot for commit 6d94c7b. Configure here.}