Repository navigation
Add macos-latest to the CI test matrix #3597
Description
Description
The macOS-only test failure reported in #3146 went unnoticed for an extended period because the CI matrix runs Ubuntu and Windows only. The failing test (test_modern_post_with_deeply_nested_body_is_rejected_not_a_crash) encodes an assumption about where CPython's recursion guard strikes, and that assumption silently broke on macOS + Python 3.14 — a platform/interpreter combination the matrix never exercised.
Adding macos-latest to the test matrix would have surfaced this at the point it was introduced rather than via a downstream bug report. The failure was deterministic and reproducible across repeated macos-latest runs, so it is a reliable signal, not flaky-runner noise.
Worth noting for scoping: the failure mode is CPython-version-sensitive (pre-3.14 the recursion limit ignores stack size entirely, so the test is deterministic and platform-independent there; on 3.14 the outcome depends on per-thread stack headroom). A macOS matrix leg therefore provides the most value on 3.14+, but including it across the supported range also guards against other platform-specific regressions in the server transport stack.
Context: this was flagged during review of #3147 (which fixes #3146) as the "more valuable half" of that issue — splitting it out so it doesn't get closed along with the PR.
References
- Deeply-nested-body test fails on macOS: rejected as INVALID_REQUEST (-32600) instead of PARSE_ERROR (-32700) #3146 — the macOS failure this leg would have caught
- fix: make deeply-nested-body test platform-independent (fixes #3146) #3147 — fix for Deeply-nested-body test fails on macOS: rejected as INVALID_REQUEST (-32600) instead of PARSE_ERROR (-32700) #3146, review discussion where the matrix gap was raised
Activity
snehasonkusare-tech commentedon Sep 29, 2026
Hi @g0rdonL, are you planning to pick this up yourself? If not, I'd be happy to take it.
My plan: add macos-latest to the test matrix in the CI workflow. To keep runner cost down, I could limit it to Python 3.14 (where the stack-headroom behaviour matters), or run it across all supported versions, whichever maintainers prefer. I'd open it after #3147 merges so the matrix doesn't go red on the deeply-nested-body test.
does that sound good? Could I be assigned?
Ben-Home commentedon Oct 2, 2026
Scoping this as a separate issue from #3147 is the right call, and the reasoning holds up - a coverage gap is fixed by adding the leg, not by patching the assertion that tripped over it.
One thing worth adding while the matrix is being touched: the CPython 3.14 sensitivity you describe (pre-3.14 the recursion limit ignores stack size, so the test is deterministic; on 3.14 it depends on per-thread stack headroom) suggests
macos-latestalone may not be stable on 3.14. Per-thread stack headroom is influenced by the runner image and thread defaults, so the same test that is deterministic on your local macOS could be borderline on a GitHub-hosted runner.Two ways to keep the signal clean:
The general point is that a CI matrix leg adding a platform is most valuable when it is paired with assertions that do not assume interpreter internals. Otherwise you have added coverage for today's runner image and will re-learn the same lesson at the next interpreter bump.
I hit this pattern whenever a test asserts on where in the stack a framework-level guard fires - the assertion is about the framework version, not about the behavior the test is named for.