No issues found across 1 file

Re-trigger cubic

Not a maintainer, just a contributor who went looking for the mechanism here because the reasoning was interesting. The fix looks right to me, and the monkeypatched test is the part I would keep regardless: relaxing the assertion alone would have quietly dropped all coverage of the RecursionError to PARSE_ERROR mapping, and pinning it separately avoids that. Two corrections to the docstring, both from measurements rather than reading.

I measured json.loads("[" * N + "]" * N) on Linux x86_64, each run in its own subprocess so a hard crash is observable, with thread stack sizes set via threading.stack_size().

1. The stack-headroom behaviour starts in 3.14, not 3.12

On 3.12 and 3.13 the flip depth is identical at 8 MB, 64 MB and 256 MB, so the guard there ignores the stack completely. Only 3.14 moves with it, and on 3.14 it is cleanly linear: roughly 8,100 levels per MB, about 129 bytes of C stack per level. Depth 100,000 needs somewhere between 12 MB and 16 MB on this platform.

This matters a little beyond wording, because the CI matrix runs 3.10 through 3.14. On everything below 3.14 the 100,000-deep body always raises and the response is always PARSE_ERROR, deterministically.

2. The macOS explanation seems to point the wrong way

The docstring attributes the macOS result to runner threads getting a smaller default stack. Following that through: a smaller stack means less headroom, so json.loads raises sooner, which gives PARSE_ERROR. That is what the original test asserted, so it would have passed.

The failure in #3146 was INVALID_REQUEST, which means the body parsed. That needs more headroom than 100,000 levels requires, not less.

My guess is that the per-level C-stack cost differs by architecture, and arm64 macOS fits 100,000 levels in a stack where x86_64 Linux needs about 16 MB. I cannot confirm that, since I only have Linux to measure on, so please treat it as a hypothesis rather than a correction to yours. Either way the conclusion is the same, and it is the one your fix already encodes: which of the two codes you get is not something the test should pin.

Suggested docstring

Something like this, if the measurements above hold up on your side:

Which JSON-RPC code it gets is platform-dependent. From CPython 3.14 the C json scanner guards recursion by actual C-stack headroom rather than a fixed limit, so whether a 100k-deep body parses depends on how much stack the parsing thread has and on the per-level cost on that architecture. It either fails to parse (RecursionError, so PARSE_ERROR) or parses into a giant list that then fails request validation (INVALID_REQUEST). Both are correct rejections; the deterministic PARSE_ERROR mapping is covered by the monkeypatch test below.

One optional idea

Since the outcome is deterministic below 3.14, you could keep the stronger assertion where it still holds:

if sys.version_info >= (3, 14):
    assert response.json()["error"]["code"] in (PARSE_ERROR, INVALID_REQUEST)
else:
    assert response.json()["error"]["code"] == PARSE_ERROR

That keeps four of the five supported versions asserting the exact code. It also adds a version branch to a test, which is its own kind of cost, so I would understand leaving it as it is.

Unrelated, and not yours to fix

On 3.12 and 3.13, a thread with a 1 MB stack segfaults parsing a deeply nested body rather than raising, because the fixed limit does not account for the actual stack available. That is CPython's, not this PR's, and the server is unlikely to parse on such a thread. Mentioning it only because the test being replaced was named ..._not_a_crash, so it seemed worth someone knowing.

Disclosure: I used AI assistance for the measurements and for writing this up. I ran them myself and can go through any of it.

All reported issues were addressed across 1 file (changes from recent commits).

Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic