You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(e2e): the Windows job's locale, not the guard, decided what 233 could read
`ci-windows-e2e` went red on 233 with
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8f in position 3037
from §7, whose `read_text()` names no encoding. Python then decodes with the
LOCALE encoding — UTF-8 on the Linux/macOS runners, cp1252 on the Windows one —
and every file this test reads (matrix.json, the engine adapters, the READMEs)
contains non-ASCII.
The crash is the benign half. cp1252 leaves only five byte values undefined, so
the reads that DON'T hit one of them succeed and return mojibake: the regex
matches nothing and the guard prints its success line while checking nothing.
§1 has been reading matrix.json that way from the start and stayed green purely
because its non-ASCII bytes missed those five. Same defect, opposite symptom —
and the silent one is the symptom this whole test exists to catch, so it must
not be the test's own failure mode.
Every read now names utf-8, including the `subprocess(text=True)` that decoded
git's stdout the same way. And the test exports PYTHONWARNDEFAULTENCODING /
PYTHONWARNINGS=error::EncodingWarning so an unspecified encoding is a hard error
on the FIRST machine that runs it — this class of bug should not be discoverable
only on Windows.
Verified both directions: with §7's encoding removed the test exits 1 locally
(EncodingWarning), restored it exits 0. The injection asserts its own anchor
first, because a sabotage that silently fails to apply reads exactly like a
passing test.
0 commit comments