fix(agents): ignore ACP-only streamTo on subagent sessions_spawn#65282
fix(agents): ignore ACP-only streamTo on subagent sessions_spawn#65282damselem wants to merge 2 commits into
Conversation
Greptile SummaryThis PR replaces a hard error for
Confidence Score: 4/5The production fix is correct, but the stale test will cause CI to fail — needs a one-line assertion update before merging. The 2-line logic change in the source file is correct and the PR description accurately describes the fix. However, the existing test that asserted the old error behavior was not updated to match the new silent-drop contract, so CI will break on the current changeset. src/agents/tools/sessions-spawn-tool.test.ts — the 'rejects streamTo when runtime is not acp' test needs to be updated to assert successful subagent dispatch instead of an error return.
|
|
Rebased onto current Greptile's earlier P1 about a stale test at |
412ef1f to
8ec72ac
Compare
|
Confirmed this is still reproducible on a newer local install and this PR matches the correct fix. Fresh findings from my environment:
Observed behavior:
I also checked the current TypeScript source in
This is the behavior we want in production, because schema-following models often emit a "complete-looking" tool payload instead of a minimal one. So from a downstream operator perspective: +1, this PR fixes a real still-active bug on current installs. |
|
We have locally validated this fix on top of OpenClaw Our test flow was:
After applying the fix, we successfully launched parallel subagent tasks using Gemini 3 Flash High and GPT-5.4. In our local validation, this removed the ACP-only Based on that result, this PR appears to be effective and was sufficient to resolve the issue in the tested |
Some callers retain ACP-only fields (streamTo) when falling back to subagent runtime. Silently drop streamTo for non-ACP requests instead of returning an error. Closes openclaw#43556 Ref: PR openclaw#55483 (correct fix, closed due to unrelated scope creep)
Updated test case to reflect new behavior for runtime 'subagent'. Changed expected status from 'error' to 'accepted' and adjusted mock call expectations.
8ec72ac to
30d3d9a
Compare
|
Triage of the 2 remaining red checks after the rebase: 1. Fails on
2. GPT-5.4 / Opus 4.6 parity gate Fails on one scenario only,
The scenario definition at In short, both reds reproduce on main or on unrelated PRs and are not attributable to this change. |
|
Closing this as duplicate or superseded after Codex automated review. Close #65282 as superseded by open PR #68397. Current main still has the reported streamTo rejection, so this is not implemented-on-main, but #68397 is the broader canonical patch for the same sessions_spawn bug because it silently strips both ACP-only fields, streamTo and resumeSessionId, for runtime=subagent and updates both regression tests. Best possible solution: Close #65282 as superseded and consolidate review on #68397 or an equivalent maintainer patch that keeps ACP behavior unchanged while silently ignoring ACP-only streamTo and resumeSessionId on native subagent spawns, with regression tests for both fields. What I checked:
So I’m closing this here and keeping the remaining discussion on the canonical linked item. Codex Review notes: model gpt-5.5, reasoning high; reviewed against d54d2d6b9b8a. |
Problem
When an agent falls back from ACP runtime to subagent runtime, it may still pass
streamTo: "parent"from the original ACP request parameters. This causedsessions_spawnto return an error:Fix
Treat
streamToas ACP-only: silently drop it when runtime is not ACP, instead of returning an error. The parameter is documented as ACP-only in the schema, so dropping it is correct behavior.Validation
Validated end-to-end on v4.11: spawned a real research subagent that ran
web_search+web_fetch, completed in 67.6s withoutcome.status = "ok"and validfrozenResultTextJSON output.References