Skip to content

test(win32): build the env-fault verify script for the host shell (#292)#301

Open
dracic wants to merge 2 commits into
bmad-code-org:mainfrom
dracic:fix/env-fault-verify-script-292
Open

test(win32): build the env-fault verify script for the host shell (#292)#301
dracic wants to merge 2 commits into
bmad-code-org:mainfrom
dracic:fix/env-fault-verify-script-292

Conversation

@dracic

@dracic dracic commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

Closes #292

Problem

test_fix_phase_session_env_fault_escalates put a POSIX check.sh into a VerifyPolicy command tuple. Verify commands run through the host shell, so on Windows cmd hands that path to ShellExecute — two failure modes, neither of which the test can see:

  • no .sh association (stock Windows): the interactive "How do you want to open this file?" picker pops mid-run and steals focus.
  • .sh associated (e.g. Git for Windows): the associated app launches and the command returns success without the script ever running — a silent false pass.

Either way the test passes, because the fault it asserts comes from an injected SessionResult(env_fault=True), so CI stayed green and only local full-suite runs saw the dialog.

Fix

Two commits, both test-only.

1. tests/test_engine.py — write check.cmd on win32, check.sh elsewhere; the POSIX branch is unchanged.

A win32 skip was rejected: the subject (#194 — a fix session that lost its API connection escalates instead of burning dev budget) is not POSIX-specific, unlike the three sibling tests, which skip on win32 because they depend on sh rc 126/127. Skipping would drop real Windows coverage of the escalation path.

Two details in the win32 branch:

  • @exit /b 0, not @exit 0 — a bare exit in a batch file terminates the invoking cmd, not just the script.
  • "\n", not "\r\n"Path.write_text uses newline=None and already translates to CRLF on Windows; the explicit \r lands on disk as \r\r\n (reproduced).

2. tests/conftest.pywrite_script_launcher had that identical redundant CR in its win32 launcher, so it gets the same correction. Harmless for a one-line launcher today, but the same defect, and fixing one site while leaving the shared helper broken would be symptom patching.

Verification

  • Windows 11: pytest tests/test_engine.py → 194 passed, 3 skipped, no dialog
  • Windows 11: pytest tests/test_engine_plugin.py tests/test_opencode_http.py (the write_script_launcher callers) → 112 passed, 4 skipped
  • Linux: pytest tests/test_engine.py -k env_fault → 6 passed, 0 skipped
  • ruff check / ruff format --check clean; tests/ is outside pyright's include

Scope

The three other inline .sh verify sites (_self_disarming_script and test_fix_phase_env_fault_escalates_instead_of_looping) are already @pytest.mark.skipif(sys.platform == "win32"), so this was the only unguarded one.

Follow-up: #302

One finding from this review is deliberately out of scope and filed as its own issue: ENV_FAULT_RCS = frozenset({126, 127}) never matches on Windows — cmd reports a missing or non-executable verify tool as 9009/1, so the charged-attempt behavior #126 exists to prevent still happens on win32, and the three skips above hide it. Reclassifying rc 1 carries a real false-positive risk (under cmd it is also the ordinary "tests failed" code), so it needs its own decision rather than riding a test-only fix.

…ad-code-org#292)

`test_fix_phase_session_env_fault_escalates` put a POSIX `check.sh` into a
VerifyPolicy command tuple. Verify commands run through the host shell, so on
Windows cmd hands that path to ShellExecute: with no `.sh` association it pops
the interactive "how do you want to open this file?" picker mid-run, and with
one it launches the associated app and returns success without ever running the
script. The test passed either way — the fault it asserts comes from an injected
SessionResult — so CI stayed green and only local runs saw the dialog.

Write `check.cmd` on win32 instead of skipping: the subject (bmad-code-org#194, a fix session
that lost its API connection escalates instead of burning dev budget) is not
POSIX-specific, unlike the three sibling tests that skip on win32 because they
depend on sh rc 126/127. The POSIX branch is unchanged.

Closes bmad-code-org#292
@coderabbitai

coderabbitai Bot commented Jul 25, 2026

Copy link
Copy Markdown

Review Change Stack

Walkthrough

The env-fault escalation test now creates check.cmd on Windows and an executable check.sh elsewhere, ensuring verify commands use a host-compatible script.

Changes

Test platform compatibility

Layer / File(s) Summary
Platform-specific verify script setup
tests/test_engine.py
The test generates a Windows batch script with exit /b 0, while non-Windows platforms continue using an executable shell script.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Suggested reviewers: pbean

Poem

A bunny hops where scripts run,
check.cmd greets the Windows sun.
Bash still burrows, neat and bright,
No dialog interrupts the night.
Tests leap onward—what a sight!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Linked Issues check ✅ Passed The test now uses check.cmd on Windows and check.sh elsewhere, preserving Windows coverage as requested in #292.
Out of Scope Changes check ✅ Passed The changes stay confined to the env-fault test and directly support the linked Windows script fix.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the Windows-host-shell test fix for the env-fault verify script.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

…rg#292 review)

`Path.write_text` uses `newline=None`, so `\n` is already translated to CRLF on
Windows — the explicit `\r` put `\r\r\n` on disk. `cmd` tolerates it for a
one-line launcher, but it is a parse hazard the moment the helper grows labels
or `goto`, and it is the same defect the per-OS script in the previous commit
was written to avoid.
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.

Windows: env-fault engine test replays check.sh through cmd — pops the 'How do you want to open this file?' dialog on every local full-suite run

1 participant