Repository navigation
Support explicit instance IDs for service-mode child workflows #850
Description
Service-mode workflow authors cannot choose a stable application ID for a child workflow. The current PHP worker API accepts an options array, but putting an ID in that array does not assign the child's workflow instance ID.
Validated public main source:
- PHP SDK
cad2b8cc53cdac36e19e563fc37565438e386f1b: WorkflowCommand::childWorkflow carries the workflow type and options into a child command. - Workflow
67833a7938b65e8ec663b4a63b25b4ac1b0beeef: WorkflowCommandNormalizer has no child instance-ID field in its normalized command. DefaultWorkflowTaskBridge::applyStartChildWorkflow creates the child instance with an engine-generated ID.
An isolated PHP 8.3 control loaded these exact source files. Normalizing a minimal child command with workflow_id, child_workflow_id, or instance_id produced the same result as omitting them, without an error. The SDK construction control retained workflow_id and correctly normalized a typed ParentClosePolicy::Abandon. This checks option handling, not a full worker/server execution.
Priority P3, additive feature. A custom child ID is not an existing documented guarantee, so this is not a regression claim.
Acceptance:
- Define one optional portable child instance-ID field and expose it through supported child-authoring options. Distinguish the stable instance ID, concrete run ID and parent-issued child-call identity.
- Keep generated IDs as the default. Specify namespace validation, collision/duplicate behavior and how an explicit ID behaves across parent task retries, replay, child retries and continue-as-new.
- Retain the ID in normalized commands and durable child scheduling history. Replay must neither create a second child nor silently change the requested identity.
- Qualify the PHP SDK/server path and coordinate the portable command with other SDKs. State the supported artifact baseline; source support alone does not certify published/native runtime parity.
- Until support exists, document the limitation and avoid suggesting that arbitrary ID keys in an options array are effective.
Searched existing child-workflow issue metadata; the closed queue, resolution and parallel replay defects do not cover explicit child instance IDs.
Activity
rmcdaniel commentedon Nov 4, 2026
Owner: Workflow for the portable embedded child-command contract; Server and all SDK owners for consumer parity; General for duplicate/reuse policy. Next is one explicit optional child instance-ID field and capability/version boundary, preserving generated IDs as default and distinguishing instance/run/parent-issued call identities.
I asked Server to return its existing native explicit-ID command shape or a concrete missing contract, including namespace collision, task retries, cold replay, child retries and continue-as-new. Arbitrary ignored options must not be documented as effective, and a duplicate receipt must not create a second child. This is separate from #989's await-started turn and #868's parent handoff. No guessed SDK field or new child writer is enabled by this inventory.
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. This P3 is next in line after those. Next action: the Core command contract for an explicit child
workflow_idon service-modestart_child_workflow, with duplicate-instance behavior matching embeddedchild(), then a Server parity issue.rmcdaniel commentedon Nov 13, 2026
Workflow owns this actionable embedded protocol change after #863/#996. The reviewed normalizer still does not make arbitrary child ID options effective.
Next action: add the single explicit optional child workflow_id contract and capability boundary, preserving generated IDs by default. Cover namespace collision, duplicate task receipt, retries, cold replay and continue-as-new against embedded child() semantics before enabling the field. Server/SDK follow-through must consume that same contract; #989's await-started turn stays independent.