-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Summary
The continueAsNew() API does not expose a way to specify a new orchestration version for the restarted instance. The underlying protobuf field (CompleteOrchestrationAction.newVersion, field 4) has existed since the initial proto commit, but the Java SDK never populates it.
Problem
TaskOrchestrationContext.continueAsNew() only accepts (Object input, boolean preserveUnprocessedEvents). There is no parameter to pass a new version. In TaskOrchestrationExecutor, when building the CompleteOrchestrationAction, setNewVersion() is never called — the field is always left empty.
This prevents version migration scenarios for long-running/eternal orchestrations (e.g., monitoring loops that need to evolve their logic over time via continueAsNew with a new version).
What exists today
- Proto layer:
CompleteOrchestrationAction.newVersion(field 4) is defined and supported by all backends (DurableTask.Core since 2014, DTS/Beskar, gRPC sidecar) - Java API:
continueAsNew(Object input)andcontinueAsNew(Object input, boolean preserveUnprocessedEvents)— no version parameter - Java executor:
CompleteOrchestrationAction.Buildernever callssetNewVersion()
Proposed fix
Follow the pattern from the .NET SDK (microsoft/durabletask-dotnet#682):
- Add a
ContinueAsNewOptionsclass withnewInput,preserveUnprocessedEvents, andnewVersionproperties - Add a
continueAsNew(ContinueAsNewOptions options)overload toTaskOrchestrationContext - In
TaskOrchestrationExecutor, whennewVersionis non-null, callbuilder.setNewVersion(StringValue.of(newVersion))on theCompleteOrchestrationAction
Related
- .NET SDK implementation: Add ContinueAsNewOptions with NewVersion support durabletask-dotnet#682
- Azure Functions extension: Add ContinueAsNew(ContinueAsNewOptions) override to FunctionsOrchestrationContext Azure/azure-functions-durable-extension#3404
- Proto field:
CompleteOrchestrationAction.newVersion(field 4) inorchestrator_service.proto