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):
- Add an optional
new_version: Optional[str] = None keyword argument to continue_as_new()
- When building the
CompleteOrchestrationAction, set new_version if provided
- Alternatively, add a
ContinueAsNewOptions dataclass if more options are expected in the future
Related
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
CompleteOrchestrationActionprotobuf message, thenew_versionfield 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
CompleteOrchestrationAction.new_version(field 4) is defined inorchestrator_service.protoand supported by all backends (DurableTask.Core since 2014, DTS/Beskar, gRPC sidecar)continue_as_new(new_input, *, save_events=False)— no version parameternew_versionis never set on the actionProposed fix
Follow the pattern from the .NET SDK (microsoft/durabletask-dotnet#682):
new_version: Optional[str] = Nonekeyword argument tocontinue_as_new()CompleteOrchestrationAction, setnew_versionif providedContinueAsNewOptionsdataclass if more options are expected in the futureRelated
CompleteOrchestrationAction.new_version(field 4) inorchestrator_service.proto