Repository navigation
Two fastify request-JSON parity tests crash under --filter json, tracked by nothing #7658
Description
Activity
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:error: `import 'fastify'` is not supported with PERRY_NO_AUTO_OPTIMIZE: the prebuilt stdlib is not compiled with `external-fastify-pump`, so fastify requests would never drain (the request loop hangs). The in-stdlib fastify adapter was removed; build without PERRY_NO_AUTO_OPTIMIZE so the stdlib is rebuilt with the fastify pump wired in.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:
- The refusal message is doing its job well — it names the missing feature (
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. - A sweep that sets
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.
- The refusal message is doing its job well — it names the missing feature (
test_issue_1240_fastify_request_jsonandtest_issue_1293_fastify_request_jsoncrash (not parity-fail) under the parity harness's--filter jsonselection. 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 unmodifiedorigin/maincheckout, 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.jsonorgap_snapshot.json, so nothing tracks them and nothing goes red on them. They are also not in the 12test_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
install_name_toolrepointing for the compiler driver, per the gc-ratchet artifact's provenance notes).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.jsonbefore (3): that file is a ratchet since #7599, and an entry without a known provenance is the suppression it replaced.