Skip to content

Replace SuggestContinueAsNew + SuggestContinueAsNewReasonTargetVersionChanged with new TargetVersionChanged flag #709

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
carlydf merged 10 commits into from
Feb 12, 2026
Merged

Replace SuggestContinueAsNew + SuggestContinueAsNewReasonTargetVersionChanged with new TargetVersionChanged flag #709

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
d9b5264
proposal
carlydf Feb 5, 2026
a95f1a2
make proto
carlydf Feb 5, 2026
574d0b9
experimental
carlydf Feb 5, 2026
4200ad8
make ci-build
carlydf Feb 6, 2026
3a4df01
make the reason a deprecated field
Shivs11 Feb 9, 2026
0c06097
revert to using reserved
Shivs11 Feb 10, 2026
9969db3
Merge branch 'master' into target-version-changed
Shivs11 Feb 10, 2026
8d32e49
regen protos
Shivs11 Feb 10, 2026
9b39410
Merge branch 'master' of github.com:temporalio/api into target-versio…
carlydf Feb 11, 2026
e3482e5
comment
carlydf Feb 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions openapi/openapiv2.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16179,11 +16179,10 @@
"SUGGEST_CONTINUE_AS_NEW_REASON_UNSPECIFIED",
"SUGGEST_CONTINUE_AS_NEW_REASON_HISTORY_SIZE_TOO_LARGE",
"SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_HISTORY_EVENTS",
"SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES",
"SUGGEST_CONTINUE_AS_NEW_REASON_TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED"
"SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES"
],
"default": "SUGGEST_CONTINUE_AS_NEW_REASON_UNSPECIFIED",
"description": "SuggestContinueAsNewReason specifies why SuggestContinueAsNew is true.\n\n - SUGGEST_CONTINUE_AS_NEW_REASON_HISTORY_SIZE_TOO_LARGE: Workflow History size is getting too large.\n - SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_HISTORY_EVENTS: Workflow History event count is getting too large.\n - SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES: Workflow's count of completed plus in-flight updates is too large.\n - SUGGEST_CONTINUE_AS_NEW_REASON_TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED: Workflow's Target Worker Deployment Version is different from its\nCurrent Version and the workflow is versioned."
"description": "SuggestContinueAsNewReason specifies why SuggestContinueAsNew is true.\n\n - SUGGEST_CONTINUE_AS_NEW_REASON_HISTORY_SIZE_TOO_LARGE: Workflow History size is getting too large.\n - SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_HISTORY_EVENTS: Workflow History event count is getting too large.\n - SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES: Workflow's count of completed plus in-flight updates is too large."
},
"v1TaskIdBlock": {
"type": "object",
Expand Down Expand Up @@ -18444,6 +18443,10 @@
},
"description": "The reason(s) that suggest_continue_as_new is true, if it is.\nUnset if suggest_continue_as_new is false."
},
"targetWorkerDeploymentVersionChanged": {
"type": "boolean",
"description": "True if Workflow's Target Worker Deployment Version is different from its Pinned Version and\nthe workflow is Pinned.\nExperimental."
},
"historySizeBytes": {
"type": "string",
"format": "int64",
Expand Down
7 changes: 6 additions & 1 deletion openapi/openapiv3.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17188,12 +17188,17 @@ components:
- SUGGEST_CONTINUE_AS_NEW_REASON_HISTORY_SIZE_TOO_LARGE
- SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_HISTORY_EVENTS
- SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES
- SUGGEST_CONTINUE_AS_NEW_REASON_TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED
type: string
format: enum
description: |-
The reason(s) that suggest_continue_as_new is true, if it is.
Unset if suggest_continue_as_new is false.
targetWorkerDeploymentVersionChanged:
type: boolean
description: |-
True if Workflow's Target Worker Deployment Version is different from its Pinned Version and
the workflow is Pinned.
Experimental.
historySizeBytes:
type: string
description: |-
Expand Down
7 changes: 4 additions & 3 deletions temporal/api/enums/v1/workflow.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -204,7 +204,8 @@ enum SuggestContinueAsNewReason {
// Workflow's count of completed plus in-flight updates is too large.
SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES = 3;

// Workflow's Target Worker Deployment Version is different from its
// Current Version and the workflow is versioned.
SUGGEST_CONTINUE_AS_NEW_REASON_TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED = 4;
// TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED is no longer a reason for suggest_continue_as_new.
// See target_worker_deployment_version_changed to find out if Target Version Changed.
reserved 4;
reserved "SUGGEST_CONTINUE_AS_NEW_REASON_TARGET_WORKER_DEPLOYMENT_VERSION_CHANGED";
}
4 changes: 4 additions & 0 deletions temporal/api/history/v1/message.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -280,6 +280,10 @@ message WorkflowTaskStartedEventAttributes {
// The reason(s) that suggest_continue_as_new is true, if it is.
// Unset if suggest_continue_as_new is false.
repeated temporal.api.enums.v1.SuggestContinueAsNewReason suggest_continue_as_new_reasons = 8;
// True if Workflow's Target Worker Deployment Version is different from its Pinned Version and
// the workflow is Pinned.
// Experimental.
bool target_worker_deployment_version_changed = 9;
Copy link
Member

@cretz cretz Feb 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

so it's easy enough to teach them to pay attention to this new TargetWorkerDeploymentVersionChanged flag.

To confirm, this is asking every SDK to add a new workflow getter? And once seen will this field need to always stay true or does it go back and forth?

I tried reading the description, but can you confirm why this is not acceptable as a CAN reason? Specifically, can you confirm will we not set suggest_continue_as_new to true once this is set? Because I would expect if suggest_continue_as_new is true, the reason would be present. And I would expect the whole reason for suggest_continue_as_new_reasons is so people can decide if the reasons represent ones they consider to be for continue as new.

Overall, the concept of suggest_continue_as_new == len(suggest_continue_as_new_reasons) > 0 is best from a comprehension standpoint, and users can choose to not adopt the suggestion. Had the reasons come before the bool, we probably would have never had the bool.

Copy link
Member

@Shivs11 Shivs11 Feb 9, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

To confirm, this is asking every SDK to add a new workflow getter?

yes

And once seen will this field need to always stay true or does it go back and forth?

I believe this field would have to be set to true, once set, for the entire duration of a workflow run. However, once it does CAN, this value would be initialized to a false. Folks could have multiple deployments of worker-versions and the idea is that on every new worker-version becoming the new "current", this getter could be set to true.

I tried reading the description, but can you confirm why this is not acceptable as a CAN reason

I think the main problem with this is simply that people were not looking at the CAN reasons when deciding if their Pinned workflows should CAN or not. When we rolled out this change, folks who had if workflow_info.suggestContinueAsNew{ do continue-as-new } in their Pinned workflows experienced non-required CAN'ing on a new deployment.

Specifically, can you confirm will we not set suggest_continue_as_new to true once this is set

Seeing this in the PR description: "I am proposing to completely remove the "new target version" reason from the can-suggested reasons list." which makes me believe that the main intention was to get rid of this reason from the list itself. I think Carly's idea is to just not use this and deviate away from this initial idea of using suggest_continue_as_new being true to using the new getter on TargetWorkerDeploymentVersionChanged.

Copy link
Member

@cretz cretz Feb 9, 2026

Choose a reason for hiding this comment

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

Ok, yes, looking for confirmation that this new getter for target version deployment changed will now be completely divorced from CAN. If it is completely separate, do want to confirm with SDK team in general that we're ok with this new workflow surface area and confirmation that once set true, it remains true for lifetime of workflow from user POV.

Copy link
Contributor

@ShahabT ShahabT Feb 9, 2026

Choose a reason for hiding this comment

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

confirmation that once set true, it remains true for lifetime of workflow from user POV.

Is that a requirement from SDK to work well? In principle, it does not have to remain true for ever because user might manually move the workflow to the new build after which the "target version changed" event becomes out of date.

Copy link
Contributor

@ShahabT ShahabT Feb 9, 2026

Choose a reason for hiding this comment

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

I'm also thinking what if we just sent the wfInfo.get_target_deployment_version and user could compare it with the wfInfo.get_current_deployment_version to make CaN decisions?

Copy link
Member

@cretz cretz Feb 9, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Is that a requirement from SDK to work well?

Not for the SDK to work well, but for user understanding. If it's a string that gets changed on successive tasks, no problem. But if it's a bool as proposed here, I would recommend the concept of changed being sticky for the rest of the workflow without having to set it to true on each successive task (meaning we memoize it as true first time we see it as true). But a bool on every successive task is probably fine too, we just need to know.

If using strings instead, feel free to only set those when changed and ask SDK to memoize first seen (we don't want duplicate data continually resent on successive history tasks).

Copy link
Contributor Author

@carlydf carlydf Feb 11, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

I'm also thinking what if we just sent the wfInfo.get_target_deployment_version and user could compare it with the wfInfo.get_current_deployment_version to make CaN decisions?

On first thought, I like this. But, thinking about it more, doing this would make it harder to protect people from the infinite CaN loop problem with our "only tell a workflow that its Target Version changed if the Target Version changed after the workflow started" solution.

So I'm going to go ahead with the current proposal.

// Total history size in bytes, which the workflow might use to decide when to
// continue-as-new regardless of the suggestion. Note that history event count is
// just the event id of this event, so we don't include it explicitly here.
Expand Down
Loading