test(cli): reproduce a provider stream disconnect failing the node in the e2e campaign (#676)

[mrthankyou]

Refs #676. This adds a reproduction, not a fix: #676 is assigned to aviggiano, and this gives a fix a test to turn green.

What it adds

• Stream-disconnect mode in the e2e stub codex (packages/cli/test/e2e/campaign-resume.test.ts), off by default. For a named node's first N calls, the stub:

  • writes some partial work into the worktree;
  • replays what codex-cli 0.144.4 prints under exec --json when its provider stream drops and stays down: five Reconnecting... n/5 errors (stream_max_retries defaults to 5), the final stream disconnected before completion: Transport error: network error: error decoding response body, and turn.failed;
  • exits 1.

  I captured that output from the real binary with an empty CODEX_HOME, pointed at a local Responses endpoint that sends response.created and then destroys the socket.

• New e2e test, "a provider stream disconnect mid-node does not fail the node":

  • gives summarize max_attempts: 1 (the issue's retries: 0) and drops its stream on the first call;
  • asserts the run ends RunFinished with summarize succeeded, which is Provider stream disconnects fail the node outright with no reconnect or resume #676's acceptance ("a regression test simulates a mid-stream disconnect and asserts the node completes");
  • first checks that the stub really dropped the stream, so a pass means a fix, not a scenario that didn't run;
  • is marked todo, so today's failure documents the bug without failing CI. A fix removes the marker.

• Refactor: the init and config steps move into initializeCampaign, shared with the resume test. Process cleanup returns no processes where there is no /proc, so the new test also runs on macOS. The existing resume test still runs only on Linux.

Reproduction result (local, macOS, pinned engine under Bun 1.3.14, about 8 minutes)

project-discovery  succeeded
summarize          failed   failure_categories: ["executor-error"]
final-report       pending
run                RunFailed
todo 1, fail 0 (suite exit 0)

So a stream drop fails the node outright as a generic executor-error. There's no transport-specific classification, which #676 also asks for.

Follow-up

The stub now has two one-off modes (hold, stream drop). #1263 proposes turning it into a shared fixture where each test picks behaviors from a scenario file, for the other agent edge cases.

Cost

One more campaign in the e2e lane, about 8 minutes locally.

🤖 Generated with Claude Code

Confidence Score: 4/5

The PR appears safe to merge, but the new test should clean up unfinished detached campaigns on macOS.

Findings

1.  Detached campaign survives cleanup ▶

Fix with agent prompt

### Issue 1
packages/cli/test/e2e/campaign-resume.test.ts:655-656
If the workflow is still running when polling times out on macOS, `processesMentioning` returns no PIDs because `/proc` is absent. Cleanup then removes the fixture without stopping the detached campaign, leaving its processes running without files they may still need. Please stop those processes before removing the fixture on platforms without `/proc`.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds a Codex stream-disconnect simulation and a TODO end-to-end reproduction, while sharing campaign initialization with the existing resume test.

• The new test exercises a failed first call to summarize and records the current run failure without failing CI.
• Cleanup for that test needs a non-/proc way to stop an unfinished campaign.

_{Reviews (1) · Last reviewed commit: "test(cli): reproduce a provider stream d..."}

[greptile-apps]

Detached campaign survives cleanup If the workflow is still running when polling times out on macOS, processesMentioning returns no PIDs because /proc is absent. Cleanup then removes the fixture without stopping the detached campaign, leaving its processes running without files they may still need. Please stop those processes before removing the fixture on platforms without /proc.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/cli/test/e2e/campaign-resume.test.ts
Line: 655-656

Comment:
**Detached campaign survives cleanup** If the workflow is still running when polling times out on macOS, `processesMentioning` returns no PIDs because `/proc` is absent. Cleanup then removes the fixture without stopping the detached campaign, leaving its processes running without files they may still need. Please stop those processes before removing the fixture on platforms without `/proc`.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[aviggiano]

Thanks for the repro. Not merging this for now:

• No CI signal, real CI cost. The test is todo, so it can never fail CI, but every e2e lane still runs a full extra campaign for it. The e2e lane took about 12 min on this PR vs about 10.5 min on others.
• The assertion is weaker than Provider stream disconnects fail the node outright with no reconnect or resume #676. A plain from-scratch retry turns it green: raise max_attempts to 2 and it passes, while the partial work is still thrown away. The partial-work-<node>.txt file is written but never checked. A real resume fix also can't pass it as written. The stub uses a different thread id on the disconnect path than on the success path, and it has no output contract for a continuation prompt.
• We're not sure Provider stream disconnects fail the node outright with no reconnect or resume #676 is still relevant in its current form. It was filed when the default profile had retries: 0, so a dropped stream failed the node permanently. Defaults now ship retry.same_agent_attempts = 3, so a disconnect is retried in a fresh session. What may be left is the lost partial work. We'd need to confirm that on a real run first. If it is still a problem, we'd want a repro that asserts the session or partial work survives a disconnect, not just that the node eventually succeeds.

Also, a heads-up: "not a fix: #676" in the description matches GitHub's closing-keyword syntax (fix: #N), so merging would have auto-closed #676.