Summary
Tracked in test-parity/known_failures.json as test_edge_error_handling (status: flake). Same flake family as test_edge_control_flow (see companion issue): failed in parity run 2026-04-25 but passed on isolated re-run with the same binary. Pre-existing, appeared between 2026-04-24 and 2026-04-25 parity runs.
The two tests appearing together strongly suggests a shared root cause — likely either runner state leak (both are large multi-section parity tests that exercise lots of HIR shapes) or non-deterministic codegen in the v0.5.x band between those two parity runs.
Test contents
test-files/test_edge_error_handling.ts — exercises throw/catch with Error/TypeError/RangeError, finally always runs, nested try/catch, error in catch block, try/catch in loop, error with custom data, multiple catch scenarios, throw string/number (non-Error), error propagation through functions, try/catch with return value, finally with return (tricky behavior). ~243 lines, ~30 console.log assertions.
How to investigate
Same procedure as the companion issue — see #272. The key questions:
- Is the failure binary-level non-deterministic? (Run the binary 100 times, hash outputs.)
- Or is it runner-level state leak? (Run just this test in isolation 100 times — if always passes, runner is leaking.)
- Is the diff content the same across multiple parity FAILures (suggesting one specific code path is racy/non-deterministic), or is the diff different each time (suggesting deeper memory unsafety)?
Recommended approach
Diagnose alongside the test_edge_control_flow issue — both should be fixed by the same change. Strong hypothesis: a shared bug in either:
- Try/catch state machine (both tests use try/catch heavily).
- Stack-frame setjmp/longjmp interaction with rayon parallel codegen (both tests have many functions, increasing the chance of parallel-codegen variance).
- A GC root that's missed during the throw/catch unwind (both tests allocate Errors heavily).
Acceptance
test_edge_error_handling passes 100/100 in repeated parity sweeps; remove from known_failures.json. Likely fixed by the same PR as the companion test_edge_control_flow flake.
Summary
Tracked in
test-parity/known_failures.jsonastest_edge_error_handling(status:flake). Same flake family astest_edge_control_flow(see companion issue): failed in parity run 2026-04-25 but passed on isolated re-run with the same binary. Pre-existing, appeared between 2026-04-24 and 2026-04-25 parity runs.The two tests appearing together strongly suggests a shared root cause — likely either runner state leak (both are large multi-section parity tests that exercise lots of HIR shapes) or non-deterministic codegen in the v0.5.x band between those two parity runs.
Test contents
test-files/test_edge_error_handling.ts— exercises throw/catch with Error/TypeError/RangeError, finally always runs, nested try/catch, error in catch block, try/catch in loop, error with custom data, multiple catch scenarios, throw string/number (non-Error), error propagation through functions, try/catch with return value, finally with return (tricky behavior). ~243 lines, ~30 console.log assertions.How to investigate
Same procedure as the companion issue — see #272. The key questions:
Recommended approach
Diagnose alongside the
test_edge_control_flowissue — both should be fixed by the same change. Strong hypothesis: a shared bug in either:Acceptance
test_edge_error_handlingpasses 100/100 in repeated parity sweeps; remove fromknown_failures.json. Likely fixed by the same PR as the companiontest_edge_control_flowflake.