Skip to content

🤖 tests: gate the fg-to-bg migration tests on a release file, not sleep 2 - #5595

Merged
ThomasK33 merged 1 commit into
mainfrom
tests/5593-fg-bg-release-gate
Oct 3, 2026
Merged

ThomasK33 merged 1 commit into
mainfrom
tests/5593-fg-bg-release-gate

Conversation

@ThomasK33

Copy link
Copy Markdown
Member

Summary

The three foreground-to-background migration tests in tests/ipc/runtime/backgroundBashDirect.test.ts relied on a fixed sleep 2: the command had to keep running for 2 s while the bash tool claimed a record name and migrated it. On Windows CI that migration can take longer, so the command finished first and the tool correctly took the normal completion path (#4878). Now each script waits for a release file that the test creates after it has checked the migration. The test then waits for the process to exit instead of sleeping 2.5 s. This is a test-only change.

Fixes #5593

Not a regression from #5579 or #5592

The same test failed on Windows before #5579 (merged 2026-10-03):

#5579 and #5592 only change the refused and failed migration paths. The successful migration path that these tests use is unchanged.

Root cause

In the merge-queue failure (run 37154303115), result.success was true but result.backgroundProcessId was undefined (backgroundBashDirect.test.ts:502). So the tool returned a normal completion. bash.ts first awaits the migration's name claim, then checks whether the command already exited, and if so completes normally. With a 2 s command, any claim slower than about 2 s produces exactly this result. Jest reported the failure location as afterAll, line 439, but the failing assertion is the one at line 502.

Validation

  • Reproduced on Linux with a probe (not committed) that delays claimMigrationProcessId by 2.5 s, which matches a slow Windows claim. On main, all three tests fail with the CI symptom:

    ● Foreground to Background Migration › should migrate foreground bash to background and continue running
      Expected: "fg_to_bg_…"
      Received: undefined
    ● … › should preserve output across stream boundaries        (Received: undefined)
    ● … › should not kill backgrounded process when abort signal fires (Received: undefined)
    

    With this change and the same probe, all four tests in that describe pass.

  • Without the probe, the whole file passes (11 tests, bun x jest, Bun 1.3.12). make static-check passes.

  • Windows: the gate path uses forward slashes (C:/…), which Git Bash accepts. The scripts never escape backslashes.


Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $47.22

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 3, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-03T22:33:50.801034Z e6db164 PR opened
🔒 Security Review ✅ Completed 2026-10-03T22:34:11.807785Z e6db164 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@ThomasK33

Copy link
Copy Markdown
Member Author

Readiness record for head e6db164:

  • CI: all required checks pass on this head (26 pass, 4 skipped). Test / Windows ran backgroundBashDirect.test.ts with the release gate and passed. The only open item is the optional Pixel / Review. Unresolved threads: 0.
  • Local: make static-check passes, and the file passes (11 tests). A probe that delays the name claim by 2.5 s makes all three old tests fail with the CI symptom (Received: undefined), and the new tests pass under it.
  • Review budget: 3 of 6 assessments (1 normal and 1 security automatic review, both with no findings, plus the final check).
  • Final independent check (clean context, on exactly this head): "ready with tracked follow-ups". No blocker. Its follow-up, the slow migration name claim on Windows, is tracked in 🤖 perf: the migration name claim can take over 2 s on Windows #5596.
  • Decision: ready. Merging with squash, pinned to this head.

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $47.22

@ThomasK33
ThomasK33 added this pull request to the merge queue Oct 3, 2026
Merged via the queue into main with commit 9f38541 Oct 3, 2026
30 of 31 checks passed
@ThomasK33
ThomasK33 deleted the tests/5593-fg-bg-release-gate branch October 3, 2026 23:13
yermakoffivan pushed a commit to yermakoffivan/mux that referenced this pull request Oct 4, 2026
…ding output (coder#5607)

## Summary

Five tests in `tests/ipc/runtime/backgroundBashDirect.test.ts` started a
short background command, slept a fixed 200 to 500 ms, then read its
output once and expected all of it. On Windows CI the command can start
writing later than that. The read then returned `""`, which is the coder#5606
failure. Each test now waits for the process to exit, using the
`waitForProcessExit` helper added in coder#5595 (bounded at 10 s), and then
reads. This is a test-only change.

Fixes coder#5606

## Root cause

In run 37169294244 (`Test / Windows`, merge group at f0ad3c6),
"should retrieve output after tools are recreated (multi-message flow)"
spawned `echo "MULTI_MSG_…"` in the background, waited 200 ms, then read
with a new `bash_output` tool. It received `""`.

Nothing lost the output. The read simply came before the slow Windows
process start had written anything. Once the process exits, a newly
created tool instance reads the full output. The fixed test shows this:
it still reads through a recreated `bash_output`. So no product fix is
needed.

The same pattern (a fixed sleep, then one read expecting complete
output) was in four sibling tests: "should read output files via
handle", "should capture stderr output when process exits with error"
(which also expects the exit code), "should capture output when script
fails mid-execution", and "should handle long-running script that
outputs to both streams". I fixed them the same way.

## Validation

- Reproduced on Linux with a probe (not committed) that delays every
background spawn by 0.5 s (`sleep 0.5;` before the script), standing in
for a slow Windows process start. On main, 4 tests fail, including the
exact CI symptom:

  ```text
● Background Bash Direct Integration › should retrieve output after
tools are recreated (multi-message flow)
    Expected substring: "MULTI_MSG_…"
    Received string:    ""
● … › should read output files via handle (works for SSH runtime)
Received string: ""
● Background Bash Output Capture › should capture stderr output when
process exits with error Expected: 1, Received: undefined
● … › should capture output when script fails mid-execution Received
string: ""
  ```

  With this change and the same probe, all 11 tests pass.
- Without the probe, the file passes (11 tests, `bun x jest`, Bun
1.3.12). `make static-check` passes.

---

_Generated with `xum` • Model: `anthropic:claude-opus-5-5` • Thinking:
`high` • Cost: `$53.84`_

<!-- mux-attribution: model=anthropic:claude-opus-5-5 thinking=high
costs=53.84 -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

🤖 flake: Windows backgroundBashDirect foreground-to-background migration test (merge queue)

1 participant