fix(stubs): named arguments no longer go missing in silence

[gplanchat]

The defect

The three __call stubs — ActivityStub, NexusStub, ChildWorkflowStub — turn the arguments they receive into a named payload. All three did it identically, and with the same defect:

$payload[$param->getName()] = $arguments[$i] ?? ($param->isDefaultValueAvailable() ? $param->getDefaultValue() : null);

PHP hands named arguments to __call in a string-keyed array. Matched by index, they answer to no $arguments[$i] — and every parameter falls back to its default value. No exception, no warning, no trace.

Here is what surfaced it: a child workflow started by

$env->childWorkflowStub(DurableAgentWorkflow::class)->run(prompt: $mission, model: 'ministral-3b-latest', maxTurns: 1)

started with prompt: null, maxTurns: 20 and the default model — then waited for a message that would never come. Diagnosed by reading the WORKFLOW_EXECUTION_STARTED payload in the Temporal history; nothing on the PHP side would have said so.

What is fixed

A single point, StubArguments::toPayload(), called by the three stubs — they were already doing the same thing, with the same mistake, and two of them would have diverged at the first partial fix.

Three behaviours, two of which were silent:

	before	after
named argument	lost, default value	matched to its parameter
explicit null	default value — the opposite of what was asked	null
unknown name (typo)	swallowed, indistinguishable from an intended default	BadMethodCallException

The second comes from ??, which conflates "absent" and "null"; hence array_key_exists. The third aligns with what PHP does with an ordinary call (Unknown named parameter).

Compatibility

No call in the repository used named arguments on a stub — verified by sweep — which explains how the defect survived. Positional calls behave exactly as before, with one exception: a null passed explicitly by position now means null and not the default. That is the fix, not a regression.

Verification

Six tests on StubArguments, one per way of getting it wrong, plus the positional reference case.

Found while writing agent delegation on spike/agent-durable-symfony-ai, which keeps a commented-out positional call in the meantime.

---

Addendum — 2026-09-04, after cross-review

No axis blocked this branch, and eight made the same remark: the principle is right and it was only half applied. The typo threw; the two other faults of the same kind stayed silent.

• A required parameter that was not supplied became null — silently, including for a non-nullable type. The payload therefore travelled into the journal, and the refusal arrived one replay pass later, in a worker, far from the offending call. That is exactly the failure mode this branch was fixing for named arguments: a fault that travels. PHP throws ArgumentCountError on the corresponding ordinary call.
• A parameter supplied both positionally and by name: the positional one won, without a word. PHP refuses ("Named parameter $x overwrites previous argument"), because there is no right answer to give.

Both now throw BadMethodCallException, like the unknown named argument. The type differs from PHP's — \Error, \ArgumentCountError — because the call goes through __call: that is the exception the SPL reserves for a method called the wrong way, and it stays catchable. The class docblock said "PHP does the same"; it now says what PHP actually does, and why the chosen type departs from it.

A variadic parameter is skipped: it has neither a default nor an obligation, so it cannot be missing, and it has no place of its own in a named payload.

testAMissingRequiredParameterIsNull codified the defect — "that is the previous behaviour, and validation stays with the handler". It is replaced by the two cases that throw, plus the neighbouring case that must keep passing: an optional parameter keeps its default, an explicit null stays null.

UPGRADE.md gains the missing note: three observable behaviours change across three published classes. It also says these exceptions are deterministic — replayed identically on every redelivery, they burn through Messenger's retries up to a failure transport.

The formatter has been run — that is what made CS red on all four PHP versions.