continue_as_new does not support specifying a new orchestration version

[YunchuWang]

Summary

The continue_as_new() API does not expose a way to specify a new orchestration version for the restarted instance. The underlying protobuf field (CompleteOrchestrationAction.newVersion, field 4) exists in the proto definition, but the Python SDK never populates it.

Problem

OrchestrationContext.continue_as_new() only accepts (new_input: Any, *, save_events: bool = False). There is no parameter to pass a new version.

When building the CompleteOrchestrationAction protobuf message, the new_version field is never set — it always defaults to empty.

This prevents version migration scenarios for long-running/eternal orchestrations (e.g., monitoring loops that need to evolve their logic over time).

What exists today

• Proto layer: CompleteOrchestrationAction.new_version (field 4) is defined in orchestrator_service.proto and supported by all backends (DurableTask.Core since 2014, DTS/Beskar, gRPC sidecar)
• Python API: continue_as_new(new_input, *, save_events=False) — no version parameter
• Proto builder: new_version is never set on the action

Proposed fix

Follow the pattern from the .NET SDK (microsoft/durabletask-dotnet#682):

1. Add an optional new_version: Optional[str] = None keyword argument to continue_as_new()
2. When building the CompleteOrchestrationAction, set new_version if provided
3. Alternatively, add a ContinueAsNewOptions dataclass if more options are expected in the future

Related

• .NET SDK implementation: Add ContinueAsNewOptions with NewVersion support durabletask-dotnet#682
• Proto field: CompleteOrchestrationAction.new_version (field 4) in orchestrator_service.proto