Skip to content

Add CONTINUE_AS_NEW_SUGGESTED_REASON and CONTINUE_AS_NEW_VERSIONING_BEHAVIOR enums. - #677

Merged
carlydf merged 45 commits into
masterfrom
trampolining2
Dec 20, 2025
Merged

Add CONTINUE_AS_NEW_SUGGESTED_REASON and CONTINUE_AS_NEW_VERSIONING_BEHAVIOR enums.#677
carlydf merged 45 commits into
masterfrom
trampolining2

Conversation

@carlydf

@carlydf carlydf commented Dec 2, 2025

Copy link
Copy Markdown
Contributor

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.

  • Allow user to specify in ContinueAsNewOptions what the initial versioning behavior of the continued-as-new workflow should be. User can say AutoUpgrade if they want their workflow to upgrade on continue-as-new.
  • Define CONTINUE_AS_NEW_SUGGESTED_REASON. suggest_continue_as_new = true, reason = TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED will be sent to the SDK with each workflow task, if the target version of the workflow is different than the deployment version that the workflow is currently on. Workflow code should listen to this and decide whether to ContinueAsNew based on the suggestion and reason(s) for the suggestion.

We want to offer a way for users to guarantee workflow pinning within a run, while still upgrading to the latest Current/Ramping version on the continue-as-new boundary.

In Phase 2 of Trampolining (which is "proactive wakeup for sleeping workflows"), a separate workflow attribute will be added to allow workflows to receive a proactive wake-up when a new version is available. Pro-active wakeup would cause sleeping workflows to wake up and have the opportunity to check continue_as_new_suggested and continue-as-new if they choose. This is orthogonal to "will I upgrade when I continue-as-new," and applicable to both Pinned and AutoUpgrade workflows.

Breaking changes

Server PR
temporalio/temporal#8784

@carlydf
carlydf requested review from a team as code owners December 2, 2025 22:20

@Sushisource Sushisource left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few comment changes. Proactively approving.

Comment thread temporal/api/history/v1/message.proto Outdated
Comment thread temporal/api/history/v1/message.proto Outdated
Comment thread temporal/api/workflow/v1/message.proto Outdated
Comment thread temporal/api/enums/v1/workflow.proto Outdated
Comment thread temporal/api/enums/v1/workflow.proto Outdated
Comment thread temporal/api/history/v1/message.proto
Comment thread temporal/api/workflow/v1/message.proto Outdated
Comment thread temporal/api/workflow/v1/message.proto Outdated
Comment thread temporal/api/command/v1/message.proto
@carlydf
carlydf merged commit e27f98c into master Dec 20, 2025
4 checks passed
@carlydf
carlydf deleted the trampolining2 branch December 20, 2025 00:10
stephanos pushed a commit that referenced this pull request Mar 10, 2026
…G_BEHAVIOR` enums. (#677)

_**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._

<!-- Describe what has changed in this PR -->
- Allow user to specify in ContinueAsNewOptions what the initial
versioning behavior of the continued-as-new workflow should be. User can
say AutoUpgrade if they want their workflow to upgrade on
continue-as-new.
- Define `CONTINUE_AS_NEW_SUGGESTED_REASON`. `suggest_continue_as_new =
true, reason = TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED` will be sent to
the SDK with each workflow task, if the target version of the workflow
is different than the deployment version that the workflow is currently
on. Workflow code should listen to this and decide whether to
ContinueAsNew based on the suggestion and reason(s) for the suggestion.

<!-- Tell your future self why have you made these changes -->
We want to offer a way for users to guarantee workflow pinning within a
run, while still upgrading to the latest Current/Ramping version on the
continue-as-new boundary.

In Phase 2 of Trampolining (which is "proactive wakeup for sleeping
workflows"), a separate workflow attribute will be added to allow
workflows to receive a proactive wake-up when a new version is
available. Pro-active wakeup would cause sleeping workflows to wake up
and have the opportunity to check `continue_as_new_suggested` and
continue-as-new if they choose. This is orthogonal to "will I upgrade
when I continue-as-new," and applicable to both Pinned and AutoUpgrade
workflows.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**
temporalio/temporal#8784

---------

Co-authored-by: Spencer Judge <spencer@temporal.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants