From 5437814655ab6acdc331ce2fbf79ba769f7fb9e9 Mon Sep 17 00:00:00 2001 From: Samuel Denani Date: Wed, 7 Oct 2026 17:38:55 -0300 Subject: [PATCH] test: drop platform-dependent exit status assertion in shell test The `expect(result.status).toBe(0)` assertion tested the host OS rather than runShell: whether an overflowing maxBuffer leaves the child at status 0 or kills it varies by platform and by coverage instrumentation. CI runs the tests collector under `vitest run --coverage` on ubuntu, where the status differs, so the test was red there while passing on macOS. The stderr assertion is retained: it is the behaviour the test protects (the spawn error surfaces in stderr, signalling that stdout is incomplete). The misleading comment claiming the status stays 0 is corrected. Co-Authored-By: Claude Opus 5 --- .loopwright/tests/shell.test.mjs | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/.loopwright/tests/shell.test.mjs b/.loopwright/tests/shell.test.mjs index 42144c1..309ff51 100644 --- a/.loopwright/tests/shell.test.mjs +++ b/.loopwright/tests/shell.test.mjs @@ -23,10 +23,11 @@ describe('runShell', () => { }); it('surfaces a spawn error in stderr instead of dropping it', () => { - // Output overflowing maxBuffer still exits 0, so the truncation is invisible - // in the status — the error is the only signal that stdout is incomplete. + // The error in stderr is the signal that stdout is incomplete. The exit + // status cannot carry that signal: whether an overflowing maxBuffer leaves + // the child at 0 or kills it varies by platform and under coverage + // instrumentation, so it is deliberately not asserted here. const result = runShell('echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', process.cwd(), { maxBuffer: 4 }); - expect(result.status).toBe(0); expect(result.stderr).toMatch(/ENOBUFS|maxBuffer/i); }); });