test(win32): build the env-fault verify script for the host shell (#292)#301
Open
dracic wants to merge 2 commits into
Open
test(win32): build the env-fault verify script for the host shell (#292)#301dracic wants to merge 2 commits into
dracic wants to merge 2 commits into
Conversation
…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
WalkthroughThe env-fault escalation test now creates ChangesTest platform compatibility
Estimated code review effort: 1 (Trivial) | ~3 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #292
Problem
test_fix_phase_session_env_fault_escalatesput a POSIXcheck.shinto aVerifyPolicycommand tuple. Verify commands run through the host shell, so on Windowscmdhands that path to ShellExecute — two failure modes, neither of which the test can see:.shassociation (stock Windows): the interactive "How do you want to open this file?" picker pops mid-run and steals focus..shassociated (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— writecheck.cmdon win32,check.shelsewhere; 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
shrc 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 bareexitin a batch file terminates the invokingcmd, not just the script."\n", not"\r\n"—Path.write_textusesnewline=Noneand already translates to CRLF on Windows; the explicit\rlands on disk as\r\r\n(reproduced).2.
tests/conftest.py—write_script_launcherhad 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
pytest tests/test_engine.py→ 194 passed, 3 skipped, no dialogpytest tests/test_engine_plugin.py tests/test_opencode_http.py(thewrite_script_launchercallers) → 112 passed, 4 skippedpytest tests/test_engine.py -k env_fault→ 6 passed, 0 skippedruff check/ruff format --checkclean;tests/is outside pyright'sincludeScope
The three other inline
.shverify sites (_self_disarming_scriptandtest_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 —cmdreports 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 (undercmdit is also the ordinary "tests failed" code), so it needs its own decision rather than riding a test-only fix.