[DRAFT/PROPOSAL] continue-as-new-suggested reason and signal

[carlydf]

What was changed

Add a system-defined signal to set workflowInfo.continueAsNewSuggested to true. Add a reason enum so workflows can see why continue-as-new was suggested whether it came from a signal or from a workflow-task-started event as usual.

Why?

So that workflows who want to upgrade their worker version via continue-as-new can find out about a new version change in their worker deployment.

Checklist

1. Closes

2. How was this tested:

3. Any docs updates needed?

---

Note

Expose reason for suggested continue-as-new and support a system signal to set it at runtime.

• Workflow runtime:
  • Add ContinueAsNewSuggestedReason enum with reasons (history size, update registry, worker deployment change) and surface via workflow.GetWorkflowInfo().GetContinueAsNewSuggestedReason().
  • Extend WorkflowInfo with continueAsNewSuggestedReason and accessor; keep continueAsNewSuggested.
  • Handle WFT started to populate continueAsNewSuggested and reason from server attributes.
• Signals:
  • Introduce system signal __suggest_continue_as_new that sets continueAsNewSuggested=true and decodes reason payload to update WorkflowInfo.
• Internal:
  • Add converter to map enumspb.ContinueAsNewSuggestedReason to SDK enum.
  • Re-export ContinueAsNewSuggestedReason in workflow/deterministic_wrappers.go.
• Deps:
  • Bump go.temporal.io/api to v1.55.1-0.20251017163919-d527807d0d4e.

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

[cursor]

Bug: Signal Handling Accesses Unchecked Payload

In handleWorkflowExecutionSignaled, processing SignalTypeSuggestContinueAsNew directly accesses attributes.GetInput().GetPayloads()[0]. This is unsafe as it doesn't validate if the input or payloads slice exists or has elements, potentially causing a runtime panic if the signal lacks expected payload data.

 

[cretz]

Proposal idea makes sense (though unsure about the details), though it's a bit strange to propose on the Go SDK, not everyone reads the Go SDK (we have more popular SDKs). May be worth proposing the problem and possible solutions internally for general SDK discussion not specific to this one SDK/PR.

[cretz]

Is this a proposal to change every SDK to accept a special built-in signal name to suggest continue as new? I would recommend keeping the one canonical place to get suggest-continue-as-new, in the task event. And if we need an RPC call to have the server apply this manually instead of how it does today, we can add it I think. Is the whole reason to use a signal because 1) we're concerned we can't send an empty task, and 2) we're unwilling to make a continue-as-new-suggested event?

If we want to take an approach like this, I think we can make continue as new suggested something that can be updated via UpdateWorkflowExecutionOptions (or separate RPC) and use WorkflowPropertiesModifiedExternallyEventAttributes or WorkflowExecutionOptionsUpdatedEventAttributes to relay the update to the SDK.

[carlydf]

Hey Chad, my intention was not for this to be ready for review as an actual ready-to-merge PR (it doesn't even have tests or a server implementation for the API change yet). I'm working on a blueprint for the PINNED_UNTIL_CONTINUE_AS_NEW behavior / "Trampolining" feature and wanted to use this PR diff as a way to communicate my initial ideas for how it could be implemented in the SDKs.

I don't intend to skip cross-SDK design for this at all. In fact, this PR is still in the design phase. Sketching it out in Go felt like the most straightforward way to get a sense of whether the implementation was technically viable, since I'm not fluent enough in any of our other SDKs to sketch it there.

I thought marking it as DRAFT/PROPOSAL while I worked on some other things would sufficiently communicate that it wasn't ready for review, but next time I'll be more explicit in the PR description as well. Keep an eye out for an incoming https://github.com/temporalio/features/issues and request for comment on my blueprint!

[carlydf]

The reason to use a signal is to provide an API through which inactive workflows can be woken up so that they have the opportunity to continue-as-new onto a new worker version even if they are waiting on a timer or other condition.

Ideally this suggestion signal / empty task / API could be exposed to users so that they can apply this suggestion to workflows when the user's specific validation requirements are met for the new version if they choose.

Signal seems like a straightforward way to do that, but WorkflowExecutionOptionsUpdatedEventAttributes + scheduling an empty task could totally do the same thing, and I think is a great option that I hadn't thought of!