test_bold_accent_renders_styled_not_bare passes alone and fails when its file runs as a whole, so any full-suite run shows one red that has nothing to do with the change under test.
Reproducing
uv run pytest tests/test_cli_theme.py::test_bold_accent_renders_styled_not_bare # passes
uv run pytest tests/test_cli_theme.py # fails
uv run pytest tests/ # fails
-p no:randomly does not change it, so this is not ordering randomisation.
What actually differs
AssertionError: expected bold + accent(#fbe23f) ANSI, got '\x1b[1;93mX\x1b[0m'
assert '1;38;2;251;226;63' in '\x1b[1;93mX\x1b[0m'
Worth noting what 93 is: bright yellow from the 8-colour palette. The test constructs its own Console(color_system="truecolor", force_terminal=True), so this is not the console degrading its colour depth -- it is emitting a named colour. The accent resolved to something like yellow rather than to #fbe23f, and Rich rendered the name.
So the leak is in the theme the console was handed, not in terminal detection.
Where to look
tests/test_cli_theme.py:21 has an autouse fixture that resets _theme._cache and clears RAVEN_THEME, RAVEN_TERM_BACKGROUND, COLORFGBG, CI, SSH_CONNECTION, SSH_TTY before each test, and nulls the cache again afterwards. Whatever survives between tests is therefore not one of those, and not the cache -- some other module-level state in raven/cli/_theme.py reached by an earlier test in the same file and never restored.
I did not narrow it to the specific test that leaves it behind.
Why it is worth fixing rather than tolerating
A permanently-red suite trains everyone to read 1 failed as normal, which is exactly when a real regression stops being visible. It also costs every contributor the same investigation -- confirming on a clean base that the red is pre-existing before they can trust their own run.
Found while verifying #308; unrelated to it and present on a clean main.
test_bold_accent_renders_styled_not_barepasses alone and fails when its file runs as a whole, so any full-suite run shows one red that has nothing to do with the change under test.Reproducing
-p no:randomlydoes not change it, so this is not ordering randomisation.What actually differs
Worth noting what
93is: bright yellow from the 8-colour palette. The test constructs its ownConsole(color_system="truecolor", force_terminal=True), so this is not the console degrading its colour depth -- it is emitting a named colour. The accent resolved to something likeyellowrather than to#fbe23f, and Rich rendered the name.So the leak is in the theme the console was handed, not in terminal detection.
Where to look
tests/test_cli_theme.py:21has an autouse fixture that resets_theme._cacheand clearsRAVEN_THEME,RAVEN_TERM_BACKGROUND,COLORFGBG,CI,SSH_CONNECTION,SSH_TTYbefore each test, and nulls the cache again afterwards. Whatever survives between tests is therefore not one of those, and not the cache -- some other module-level state inraven/cli/_theme.pyreached by an earlier test in the same file and never restored.I did not narrow it to the specific test that leaves it behind.
Why it is worth fixing rather than tolerating
A permanently-red suite trains everyone to read
1 failedas normal, which is exactly when a real regression stops being visible. It also costs every contributor the same investigation -- confirming on a clean base that the red is pre-existing before they can trust their own run.Found while verifying #308; unrelated to it and present on a clean
main.