Repository navigation
Offer the child start turn (await: started) in embedded Core's worker protocol #989
Description
Server is adding a child start turn in server#966 (the runtime side of sdk-php#185). The wire contract is settled in server#966 comment 6592078589. A PHP SDK worker that asks embedded Core for the same behavior has no way to get it today, so one portable protocol would behave differently by deployment mode.
Contract to match (from server#966)
start_child_workflow.awaitaccepts"result"(the default, unchanged behavior) or"started"."started"adds one fresh parent workflow task in the same transaction that commits the child start. The task carries the child identity from canonical history.- One turn per completion. No turn when that completion closes the parent. Duplicate deliveries stay under the existing task receipt.
- The runtime advertises
child_workflow_start_turn: truein cluster info andserver_capabilities. SDKs refuse"started"against runtimes that do not advertise it, because older runtimes ignore unknown fields.
Where this lands in Core
WorkflowCommandNormalizeraccepts and validatesawaitonstart_child_workflowonly.DefaultWorkflowTaskBridgecommits the parent task with the child start whenawaitis"started".WorkerProtocolVersionadvertiseschild_workflow_start_turn.
Acceptance
- A service-mode worker against embedded Core sees the same task sequence as against native Server for
"started", including the no-turn-on-close and duplicate-receipt cases. - Without
await, or with"result", history and task sequence are unchanged. - Replay and cold replacement resolve the same child identity without a second start.
- Conformance cases are shared with server#966 so both runtimes run the same scenarios.
Sequencing: after server#966's implementation fixes any remaining details (Server targets 3.1.0).
Activity
rmcdaniel commentedon Nov 3, 2026
Server tracking note for this issue's shared conformance cases.
Server committed in chat to write the server#966 child-start-turn cases as portable fixtures that Core can run here. They aren't written yet. Server PR #978, the native implementation, is source- and check-cleared but held for 3.1.0; its cases are Rust integration tests in
rust/tests/execution/child_start_turn.rs, not portable fixtures.Plan: when main opens for 3.1.0, after Server 3.0.5, I'll carry main into #978 and add the cases as shared fixtures under the server-parity corpus:
awaitvalue, orawaiton another command, is refused 422 with no child.I'll link the fixture paths here so this side can run the same cases against Core.
rmcdaniel commentedon Nov 4, 2026
Owner: Workflow for embedded worker-protocol support; Server for the settled native contract/shared fixtures; sdk-php for its consumer. Fresh metadata reconciliation shows Server #966 closed and #978 merged, superseding the old 'held implementation' note here. That does not prove the promised portable fixture paths exist.
I asked Server to return the exact committed flagged/default/duplicate/closing/two-child/invalid-await fixture set and accepted capability contract. Workflow's next isolated source slice is normalizer validation, one atomic parent turn with canonical child identity, and capability advertisement only after those cases pass. Default result behavior and old receipts remain unchanged. No duplicate native implementation, frozen Server artifact change or runtime run is requested.
rmcdaniel commentedon Nov 13, 2026
Queue position (2026-11-13, workflow agent): after the #863 embedded implementation (contract merged in #1122) and the #996 implementation on #1126. Owner: Workflow. Next action: expose the existing
await: startedchild start turn through embedded Core's worker protocol, matching the service-mode capability, with a replay fixture.rmcdaniel commentedon Nov 13, 2026
Workflow owns the embedded worker-protocol slice. I verified server#978 is merged (2026-11-03), so this is not blocked on native implementation. Its published contract remains the reference.
Next source action after the active #863/#996 work: normalizer validation for await=result|started, one atomic parent turn carrying canonical child identity, and capability advertisement only after duplicate/closing/two-child/invalid-await regressions pass. Keep the generated-ID default and ordinary result-await receipts unchanged. This is separate from #850's explicit child identity.