Repository navigation
Two fastify request-JSON parity tests crash under --filter json, tracked by nothing #7658
Description
test_issue_1240_fastify_request_json and test_issue_1293_fastify_request_json crash (not parity-fail) under the parity harness's --filter json selection. Both are fastify HTTP-server tests.
Found incidentally while re-measuring #7478 on the pinned quiet mini: 35 tests matched --filter json, 33 passed, 0 parity-failed, and these 2 crashed. Reproduced on the mini's unmodified origin/main checkout, so they are pre-existing and were not caused by the change under test (a docs-only diff).
Why this is worth a ticket rather than a note
Neither test appears in test-parity/known_failures.json or gap_snapshot.json, so nothing tracks them and nothing goes red on them. They are also not in the 12 test_gap_*json* tests that the JSON work routinely runs — they only surface under a broader --filter json, which is why a whole campaign of JSON work (#7477, #7483, #7499, #7537, #7539, #7546, #7478) never saw them.
A crash is a stronger signal than a parity failure: it is a wrong answer that could not even finish producing itself. Two of them, in the same subsystem, unattributed.
What to establish first
- Whether they crash on a dev host too, or only on the mini — the mini's toolchain differs (it carries z3 4.16 and needs
install_name_toolrepointing for the compiler driver, per the gc-ratchet artifact's provenance notes). - Whether the crash is in fastify's request handling or in JSON parsing reached through it. If the latter, it belongs with the tape work; if the former, it is an HTTP-server bug that merely mentions JSON.
- Whether they ever passed —
git logon the test files plus a spot-check at an older tag would say whether this is a regression or has never worked.
Do not add them to known_failures.json before (3): that file is a ratchet since #7599, and an entry without a known provenance is the suppression it replaced.
Activity
proggeramlug commentedon Aug 8, 2026
Closing — not a crash, and my filing was wrong. These two tests do not crash; they refuse to compile under
PERRY_NO_AUTO_OPTIMIZE=1, deliberately and with an explicit message:Compiled the way the test actually requires — no
PERRY_NO_AUTO_OPTIMIZE—test_issue_1240_fastify_request_json.tsbuilds at exit 0, zero errors, and runs:Server listening on http://0.0.0.0:18997. It is a long-running wire-level server test with its own driver (test-files/run_test_issue_1240.sh, which POSTs and asserts on the response), so a bare invocation correctly sits in its request loop until killed.The real finding is a harness trap, and it is mine. I have been putting
PERRY_NO_AUTO_OPTIMIZE=1in every agent brief — it avoids ~1 GB oftarget/perry-auto-*per compile, which is a real problem (one agent minted 34 of them and filled the volume). But it makes every fastify test fail with the refusal above, and a broad--filter jsonsweep picks exactly those up. That is what produced the '2 crashes' report this issue was filed on.So there is nothing to fix in the tests. Two things worth carrying instead:
external-fastify-pump), the consequence (the request loop would hang), and the fix, rather than failing at link time or hanging. That is why this was diagnosable in one compile.PERRY_NO_AUTO_OPTIMIZE=1should either exclude the auto-opt-requiring tests or report them as skipped rather than failed. Filed separately if it recurs; not worth a ticket on the strength of one sweep.Thanks to the #7478 re-measure for surfacing it — the observation was accurate, my interpretation of it was not.