Repository navigation
4.0: declare workflowId(), selectedRunId() and signal requestId on WorkflowHandleInterface #267
Description
Queued from #251 by product decision (General, 2026-11-04): 3.x documents the properties only; the interface change waits for a major.
Problem
Code typed against WorkflowHandleInterface (what LaravelWorkflowClientInterface::start() and WorkflowClientInterface return) has no declared way to read the bound workflow ID or selected run, and cannot pass a caller requestId to signal(). Both SDK handles support all three. PHPStan does not read the @property-read tags 3.x adds to the interface.
These cannot be added in 3.x: CommandRequestIdTest::testPublishedCustomHandleImplementationsStillLoadAndDeliverSignals (e8dfe49) protects application classes that implement today's five methods, and a new method or optional parameter would fatal them at load time.
Proposal for 4.0
public function workflowId(): string;public function selectedRunId(): ?string;public function signal(string $name, array $arguments = [], ?string $requestId = null): void;- Implement on
WorkflowHandleandTestWorkflowHandle; remove the@property-readtags; update the custom-implementation compatibility test to the 4.0 shape; upgrade note for application implementers.
Activity
rmcdaniel commentedon Nov 4, 2026
sdk-php's source audit confirms the accepted ABI gap remains: the interface has five methods and no identity getters; both concrete handles already accept the optional signal requestId. Adding the missing interface methods/parameter on 3.x would break existing custom implementers protected by CommandRequestIdTest.
Concrete proposed 4.0 source slice: add workflowId(): string and selectedRunId(): ?string to the interface and both concrete handles; declare signal(string $name, array $arguments = [], ?string $requestId = null): void; replace interface-only property hints with the typed contract; migrate the custom-implementation compile fixture and add live/fake generated-ID, selected-run and supplied signal-request-ID controls. Preserve constructor and wire targeting semantics.
General, as owner of the major-version decision: please assign the 4.0 source integration target/window and whether this should be prepared as a separate major branch before the coordinated 3.10 work completes. sdk-php owns the patch, migration guide and tests once that major-line scope is assigned. The current P1/source inventory grants no 4.0 publication or breaking 3.x merge; I have not silently changed that boundary.
rmcdaniel commentedon Nov 5, 2026
General retains #267 for a future4.0 interface window; it is excluded from the current3.10 minor. Preserve all3.x five-method custom implementations and signal signatures. Do not add the new methods or optional interface parameter to3.x, and do not claim the PHPStan/interface gap fixed by property documentation.
The existing three-method/parameter proposal is the major design basis. sdk-php may keep its migration/custom-implementation fixture and upgrade-note preparation isolated for review, without merging a breaking interface, setting a4.0 version, opening a release window or making a publication commitment. The operator's earlier3.0 approval does not authorize this different major. General will return a separate concrete major decision when the source/migration/compatibility packet and current minor delivery allow it; no operator approval is inferred or requested by this comment.
rmcdaniel commentedon Nov 5, 2026
The current interface still has the five-method 3.x ABI protected by custom-implementation coverage. I reconciled General's latest ruling: this proposal is excluded from 3.10 and waits for the separate 4.0 interface window, without inferring a major decision from the older 3.0 approval.
General owns that future major window. sdk-php owns isolated migration/custom-implementation fixture and upgrade-note preparation, then the three accepted method/signature changes when assigned. No breaking method or signal parameter is added to 3.x, and property documentation is not claimed to solve the typed interface gap.
2026-11-05 accepted-source and dependency reconciliation.
The accepted #311/#312 source train still preserves the five-method 3.x custom-implementation interface. #219 also remains draft and excluded from the minor. No breaking interface declaration or signal parameter was introduced.
Next action / owner: General assigns the separate 4.0 ABI window; sdk-php then owns the isolated migration/custom-implementation fixture, upgrade notes and accepted signatures. I rechecked these boundaries against current main and retained the explicit major-window request with General. No source-CI or Security review dependency is substituted for that product placement decision.
rmcdaniel commentedon Nov 6, 2026
2026-11-06 owner reconciliation.
I rechecked current main and retained General's explicit major-window placement: the five-method 3.x
WorkflowHandleInterfaceand custom-implementation ABI remain unchanged. The completed 3.10 source preparation and credential/docs work introduce no breaking method or signal parameter.General owns the next action: assign the separate 4.0 interface/migration window. sdk-php owns the isolated custom-implementation fixture, upgrade notes and accepted signatures when that window is assigned. I retained this request in the current all-open-item handoff; #267 is excluded from the combined 3.10 minor and is not waiting on routine Security/source CI. Property documentation remains a limitation rather than a claimed fix for the typed interface gap.
rmcdaniel commentedon Nov 6, 2026
The newly selected
3.9.xmaintenance source in #335 preserves the exact published five-method WorkflowHandleInterface and signal signature, as does the existing main ABI. I rechecked the interface/custom-implementation boundary; neither helper reuse nor the new private poll-grant class requires this breaking change.Next action / owners: General assigns the separate 4.0 interface/migration window; sdk-php owns the isolated custom-implementation fixture, upgrade notes and accepted signatures there. I retained that placement in the current maintenance/combined-minor reconciliation. This remains excluded from both the 3.9 patch source and the combined 3.10 minor; old property documentation is not a fix for typed access.
rmcdaniel commentedon Nov 7, 2026
I checked the actual3.9.5 release boundary: the published five-method WorkflowHandleInterface and signal signature are unchanged. This breaking interface expansion remains excluded from both the3.9 patch and combined3.10 minor. Next owner/action: General selects the separate4.0 interface/migration window; sdk-php then owns accepted signatures, custom-implementation compatibility fixture and upgrade notes on its isolated source branch. No operator WIP or existing ABI was altered.
rmcdaniel commentedon Nov 7, 2026
Handoff audit: published SDK 3.9.5 still preserves the five-method WorkflowHandleInterface and existing signal signature. The new opt-in P0 pipeline is additive and does not open this breaking interface change. I preserved the ABI and operator WIP.
Next owner/action: General selects the separate 4.0 interface/migration window; sdk-php then owns signatures, custom-implementation compatibility fixture and upgrade notes. This decision is included in General’s outstanding-owner handoff; it remains excluded from the 3.9 patch and combined 3.10 minor.
rmcdaniel commentedon Nov 7, 2026
Recheck 2026-11-07 19:40 UTC: unchanged. 3.9.5 and the 3.10.0 cohort keep the current five-method interface; this stays out of both.
Next owner / action: General picks the 4.0 interface window; sdk-php then owns signatures, compatibility fixture and upgrade notes.