`conformance-smoke` fails 8/8 shards: 12 real regressions, 10 newly-visible node_fail transitions, 1 fix the snapshot hasn't accepted

[proggeramlug]

Summary

conformance-smoke is a required status context and it fails 8 of 8 shards on every recent PR. I pulled all eight shard logs from #8090's completed run and tallied the actual gate output. It is not flake, and it is not one cause — there are 23 status changes in four distinct categories.

CLAUDE.md warns that these shards are flaky and that a red shard should be re-run and A/B'd before being believed. Eight of eight is not the flake signature, which is why I went looking.

The tally

 10  node_fail  -> parity_fail
  8  pass       -> parity_fail
  3  pass       -> crash
  1  pass       -> compile_fail
  1  parity_fail -> pass

10 × node_fail -> parity_fail — previously invisible, now exposed

test_gap_4510_enum_forward_ref          test_gap_moment_methods
test_gap_backoff_options                test_gap_prop_plan_cache_invalidation
test_gap_cron_cronjob                   test_gap_ratelimiter_memory
test_gap_dayjs_factory_arg              test_gap_slugify_options
test_gap_derived_param_props            test_gap_enum_in_function_body

This is exactly the #6364 pattern CLAUDE.md documents: when the oracle cannot run a test it exits non-zero, the harness classifies it node_fail, and the test is silently dropped from the gate rather than going red. These ten were in that hidden state and are now running — so these are not new breakage, they are newly visible breakage. The shard header says so itself: "STATUS CHANGES — including tests the oracle stopped covering".

That makes them the least urgent of the four groups and arguably good news, but they must be triaged and recorded rather than left to hold the gate red.

12 × genuine regressions from pass

pass -> crash          test_gap_6386_dataview_concat_regex_fastpaths
                       test_gap_7238_i64_specialization_exactness
                       test_gap_buffer_own_props
pass -> compile_fail   test_gap_zlib_4917_level
pass -> parity_fail    test_gap_array_methods
                       test_gap_builtin_alias_construct_7524
                       test_gap_collection_foreach_member_receiver_thisarg
                       test_gap_dynamic_builtin_construct_dispatch
                       test_gap_new_globalthis_builtin_6726
                       test_gap_set_map_foreach_fused_receiver
                       test_gap_specabi_reassign
                       test_gap_sso_concat_string_index

These are the ones that matter. Three pass -> crash are the worst of them. test_gap_specabi_reassign is #8100, fixed by #8109 — so at least one of the twelve is already resolved, which suggests the rest are individually tractable.

I have not attributed these to a commit. They are red with similar counts on every PR I checked, so they are almost certainly main-side rather than any one PR's doing, but that is an inference and someone should bisect rather than trust it.

1 × parity_fail -> pass — a fix that fails the gate

test_gap_iterator_helpers_2874 now passes and the snapshot still lists it as failing. The snapshot gates divergence in either direction by design, so an improvement turns the gate red until the snapshot is regenerated. Working as intended, but worth naming: part of why this context is red is that something got better.

Why this matters beyond the tests themselves

conformance-smoke-complete is one of seven required contexts. With it red, no PR can merge without admin bypass, which is the "required and always red trains bypass" failure mode CLAUDE.md calls out — and it is how #8100 (a silent wrong-answer miscompile in the shipped default) sat unnoticed. Its shard was cancelled early on recent runs, so nothing surfaced it.

Tracking the required-context picture in #8092. The others: lint is fixed as of #8087; cargo-test fails on four ELF-only byte-identity tests; parity/compile-smoke report SKIPPED by design and are continue-on-error.

Suggested split

1. Triage the 10 node_fail -> parity_fail and record them in test-parity/gap_snapshot.json with issue links — they were always broken and are cheap to classify.
2. Bisect the 12 genuine regressions. Three crashes first.
3. Regenerate the snapshot for test_gap_iterator_helpers_2874.
4. Only then is the gate meaningful enough to keep required.

Reproduce with ./scripts/run_gap_tests.sh --shard N/8.

[proggeramlug]

Independent corroboration from a local gap run

An agent running the full gap suite locally (a different worktree, a different build, no CI involvement) hit the same set. Two of the twelve pass -> regressions reproduced by name:

test_gap_array_methods                                Int32Array.toSorted/.toReversed/.with -> "[]"
test_gap_collection_foreach_member_receiver_thisarg   "set member no-thisArg:" -> "[]"

and five of the ten node_fail -> parity_fail transitions also reproduced (enum_forward_ref, backoff_options, cron_cronjob, dayjs_factory_arg, derived_param_props).

That matters for the attribution I left open above. Two independent methods — CI's sharded run and a local full run on an unrelated branch — agreeing on the same names is much stronger evidence that these are main-side than my inference from "red on every PR I checked".

The local run also adds a control I could not get from CI logs: both regressions reproduce identically under PERRY_SPECIALIZED_ABI=0, so they are not representation-selection or specialized-ABI effects.

Two notes on the middle group: the agent characterised those five as environment drift rather than code — the snapshot recorded node refusing TS enums and failing to resolve exponential-backoff without node_modules, and here node executes both. Consistent with the #6364 reading above, and it means a snapshot refresh clears them rather than a fix.

One of the twelve now has an owner: test_gap_array_methods is the sort/with/toReversed family that #8090's changelog names as "same-class cases still open", tracked as #8096 with a fix in flight. That leaves eleven unowned, three of them crashes.

[proggeramlug]

Second corroboration, and a lead on two of the twelve

A full 559/559 local gap run (different host, different branch, GAP_HARNESS_EXIT=1, no partial) reported seven regressions. All seven are in the twelve catalogued above, including both non-parity classes:

array_methods                              pass -> parity_fail
collection_foreach_member_receiver_thisarg pass -> parity_fail
set_map_foreach_fused_receiver             pass -> parity_fail
specabi_reassign                           pass -> parity_fail   (fixed since, by #8109)
sso_concat_string_index                    pass -> parity_fail   (fixed since, by #8109)
7238_i64_specialization_exactness          pass -> crash
zlib_4917_level                            pass -> compile_fail

It also independently confirmed the improvement: test_gap_iterator_helpers_2874: parity_fail -> pass.

The lead: two of them fail only in-suite

test_gap_7238_i64_specialization_exactness and test_gap_zlib_4917_level do not reproduce standalone. Run by hand they are byte-for-byte identical to node with exit 0.

The first reading was host load — that run executed above load 100 with auto-optimize lock serialization, and the harness's own wording for the crash class is "died from a signal or timed out". But CI classified them the same way (crash, compile_fail) on GitHub runners, which is a different host under different load. Two independent environments producing identical classifications is not the usual signature of a timeout artifact.

So the better characterisation is "fails in-suite, passes standalone, on two independent hosts" — which points at test isolation or ordering rather than the code under test. That is a much cheaper thing to chase than a miscompile, and it should be checked before anyone bisects those two: if they are ordering-dependent, a bisect will produce a confident wrong answer.

Progress on the twelve

Three now have fixes on main: specabi_reassign and sso_concat_string_index (#8109), array_methods (#8119, closing #8096). That leaves nine, of which collection_foreach_member_receiver_thisarg and set_map_foreach_fused_receiver are the same empty-collection family and look like one bug rather than two.

[proggeramlug]

Status of the twelve after tonight's merges — measured, not inferred

A post-rebase retest on 83b6b8c69 (which now carries #8106, #8109, #8118, #8119, #8120) re-ran the affected entries individually. Two are fixed; ten remain.

#	test	state
1	6386_dataview_concat_regex_fastpaths	red — crash
2	7238_i64_specialization_exactness	red in-suite, passes standalone
3	array_methods	✅ fixed by #8119 (#8096)
4	buffer_own_props	red — crash
5	builtin_alias_construct_7524	red
6	collection_foreach_member_receiver_thisarg	red, unowned
7	dynamic_builtin_construct_dispatch	red
8	new_globalthis_builtin_6726	red
9	set_map_foreach_fused_receiver	red, unowned
10	specabi_reassign	✅ fixed by #8109 (#8100)
11	sso_concat_string_index	red — see below
12	zlib_4917_level	red in-suite, passes standalone

sso_concat_string_index was predicted fixed and is not

Worth recording because the reasoning failed in an instructive way. #8109's commit message says it re-tags "a heap string so it reaches the string arm rather than the ObjectHeader walk", which reads like general coverage of string indexing. It is not — that describes one arm of that change, and this case is outside it.

Reading a commit message is not reading the diff. The prediction was recorded in advance, which is the only reason the miss was visible at all; without it the observation would have been "three still red" with no signal that an expectation had been violated.

This one now looks like it wants an owner: it is red standalone, and the two fixes that landed in its neighbourhood did not touch it.

Remaining shape

• Two crashes (6386_dataview_concat_regex_fastpaths, buffer_own_props) — most severe, unowned.
• Two in-suite-only (7238_i64_specialization_exactness, zlib_4917_level) — do not bisect these before establishing isolation; an ordering-dependent failure will hand a bisect a confident wrong answer.
• Two in the same empty-collection family (collection_foreach_member_receiver_thisarg, set_map_foreach_fused_receiver) — plausibly one bug.
• Four others red standalone.

So the ten split into roughly six investigations, not ten.

[proggeramlug]

The two pass -> crash entries: both are SIGSEGV, both are 12 days old, and they bisect to #7314 — nothing merged tonight

Taking 6386_dataview_concat_regex_fastpaths and buffer_own_props. Three things are measured below; one reading at the end is explicitly labelled inferred.

1. They are signals, not timeouts

From the eight shard logs of #8090's run (31825115698), pulled with gh api repos/:owner/:repo/actions/jobs/<id>/logs:

CRASH test_gap_6386_dataview_concat_regex_fastpaths (SIGSEGV (exit 139))
      Perry died after printing 13 line(s); Node exited 0.
CRASH test_gap_buffer_own_props (SIGSEGV (exit 139))
      Perry died after printing 11 line(s); Node exited 0.

The 13th/11th "line" is bash's own Segmentation fault message, captured by the harness's 2>&1. So the real counts are 12 and 10.

For contrast, in that same run 7238_i64_specialization_exactness is TIMEOUT (killed after 10s) — a genuinely different class, consistent with the "in-suite only" reading already in this thread.

2. A zero-build bisect over the archived CI logs

For each historical PR run I downloaded its eight conformance-smoke shard logs and read the PASS/CRASH verdict for these two names, then resolved each run's head sha to the main commit it branched from (gh api repos/:owner/:repo/compare/main...<sha> --jq .merge_base_commit). No builds involved.

Both tests PASS on every probed run from 2026-07-28 through 2026-08-03 13:49, and CRASH from 2026-08-03 15:41Z onward:

run	branch	main merge-base	base UTC	buffer	dataview
30826172101	gc/7280-dep-corpus	b50e857c2	13:37	PASS	PASS
30828209038	exp/stackmap-viability	b50e857c2	13:37	CRASH	CRASH
30826965091	fix/7311-multi-operand-reload	2fc383a6f	15:13	PASS	PASS
30828385716	feat/gc-schedule-seed-fuzzing	6bedb2574	15:20	PASS	PASS
30829166093	docs/7314-plan-status	61a789f7c	15:41	CRASH	CRASH
30829805015	fix/node-module-node26-parity	6fe493920	15:48	PASS	CRASH
30830497975	gc/7314-followup-cross-function-match	6fe493920	15:48	CRASH	CRASH
30830932181	fix/loop-safepoint-purity-knob	93f5029e6	16:06	CRASH	CRASH

git log 6bedb2574..6fe493920 is exactly two commits and the later one is docs-only, so the window holds one code commit:

61a789f7c — Native-frame GC roots via LLVM statepoints, opt-in (#7173, #7174) (#7314)

Two rows make that airtight rather than circumstantial:

• rows 1 and 2 share the same main base b50e857c2 and differ only by Native-frame GC roots via LLVM statepoints, opt-in (#7173, #7174) #7314's diff — exp/stackmap-viability is Native-frame GC roots via LLVM statepoints, opt-in (#7173, #7174) #7314's development branch. Without the diff: pass. With it: crash.
• row 5 is a documentation-only branch based exactly on 61a789f7c, and it crashes. So main at that commit is bad, and no branch content is doing the work.

Controls: the runner image is identical across the boundary (ubuntu-24.04 / 20260720.247.2, provisioner 20260707.563) on every row above, so this is not an image rotation.

They are also intermittent. After 08-03 each test independently flips: buffer PASSes on 08-10, dataview PASSes on 08-08/08-09/08-13. Roughly 65–80% crash rate each. That is the signature CLAUDE.md gives for an unrooted register — "goes bad only when a collection lands in its window" — not a deterministic miscompile, and not an unrooted cache (which would be perfectly reproducible).

3. Where each one dies

The line counts are trustworthy: js_console_log prints through Rust's println!, and Rust's Stdout is a LineWriter — it flushes on every newline whether or not stdout is a TTY — so nothing is lost in a buffer when the process dies.

• buffer_own_props printed all 10 of its lines, then faulted. That is the generated exit epilogue (codegen/entry.rs loop_exit): js_process_emit_before_exit → js_promise_run_microtasks_event_loop (an outermost microtask-pump GC safepoint) → timers → js_process_run_finalization_exit → … → js_gc_release_current_thread_collection_side_allocations.
• 6386_dataview printed 12 — through dv shadowed: 43, the last statement of the DataView block — and faulted before concat hot:. What follows is 200 pushes and 500 × [].concat(x, y) over 200 elements, the file's first heavy-allocation loop, i.e. the first loop back-edge poll / moving minor after that block.

Shared shape: the first moving minor after an own property is stored onto a Buffer/DataView. 6386's v3 is const inside a { … } block, so by the concat loop it is dead while buffer_props[addr(v3)] still holds its entry (a closure) keyed by a dead address. buffer_own_props keeps its Buffers module-level, so its entries stay live and its crash lands at the exit-boundary pump instead. Of the 559 gap fixtures, a grep for an own-property assignment onto a Buffer/DataView receiver matches essentially only these two.

4. They do not reproduce on macOS/arm64

Release build at 83b6b8c69, PERRY_RUNTIME_DIR pinned, grep -c "Compiling perry-runtime v" = 1. Both fixtures are byte-identical to node v26.5.1 with exit 0, and stable across 30 consecutive runs each, with auto-optimize and without, and under PERRY_GC_ZEAL=1, PERRY_GC_ZEAL_ALLOC_KB=0, PERRY_GC_PROTECT_FROMSPACE=1 …_DEPTH=800, PERRY_GC_FORCE_EVACUATE=1, PERRY_GC_VERIFY_EVACUATION=1, PERRY_GC_FROMSPACE_SCAN=1, PERRY_GC_SCHEDULE_RATE=1 across seeds, and PERRY_GEN_GC=0. The from-space scan reports dangling=0 owners=0 every time. This is not "statepoints are off locally" — otool -l shows a real __PERRY_GCMAP/__perry_gcmap section in the compiled fixture, so the native-root backend is live here too.

So the axis is Linux, not in-suite-vs-standalone — a different answer from the one #7238/#zlib got.

5. The mechanism — this part is inferred, not measured

Every behavioural change in #7314 is gated behind statepoints_enabled() / rs4gc_enabled() / native_stack_roots_enabled() / gc_safepoint_only_contract_enabled() / stack_map_requested, all default-off at that commit. I read every hunk; function.rs has 4 removed lines and 1197 additive gated ones, module.rs's per-bucket global emission and linker.rs's clang concurrency only fire for multi-unit modules (render_codegen_units(1) == to_ir(), and a one-file gap fixture is one unit), and contract_scan_heal_guard() / visit_stack_map_root_slots both early-return when off.

There is exactly one unconditional addition: initialize_stack_maps() in js_gc_init. On macOS it resolves through _dyld_get_image_header and allocates nothing. On Linux, at that commit, it is:

#[cfg(target_os = "linux")]
fn loaded_stack_map_section() -> Option<&'static [u8]> {
    let bytes = std::fs::read("/proc/self/exe").ok()?;   // the ENTIRE executable
    let (addr, size) = elf_section_vaddr(&bytes, b".perry_gcmap")?;
    ...
}

So from 61a789f7c on, every Perry binary on Linux reads its own 5–13 MB image into a heap Vec at startup and frees it, before any user code runs, then returns None because a shadow-stack build has no such section. That moves every subsequent mmap and arena-block placement, it is Linux-only, and it lands exactly at the boundary. It is the best available explanation for "the diff is gated off and the tests flipped anyway, on Linux only" — i.e. #7314 most likely perturbed a latent bug rather than introducing a new code path, the same "allocator property, not a program property" class #7747 named for this exact test family.

Two consequences if that reading holds: reverting #7314 is not the fix (it is the default root lowering now), and the real defect is older than 08-03 and still unnamed.

Worth a separate look regardless: current main has expanded that startup read — loaded_stack_map_sections (#8075) now std::fs::reads every dl_iterate_phdr image, the executable plus every shared object, on every Linux start.

6. Two concrete defects in that neighbourhood, found by reading

Neither is proven to be the crash; both are real.

1. finalize_collected_dead_buffer (buffer/header.rs:675) never prunes the buffer own-property table. Its docstring is "Drop every registry/side-table entry keyed by a dead buffer's address" and it prunes ten of them — BUFFER_REGISTRY, ARRAY_BUFFER_REGISTRY, SHARED_ARRAY_BUFFER_REGISTRY, DATA_VIEW_REGISTRY, BUFFER_AB_ALIAS, CRYPTO_KEY_META_REGISTRY, SECRET_KEY_REGISTRY, UINT8ARRAY_FROM_CTOR, the three external_* maps, plus detach:: and view:: — but not own_props::clear_buffer_own_props. Its only caller is register_buffer, so an entry is dropped only when the address is re-registered as a buffer. Result: an unbounded leak, scan_buffer_own_props_roots_mut retaining a dead buffer's closure forever, and an entry whose key visit_metadata_usize_slot keeps re-resolving against whatever now owns that address.
2. scan_buffer_own_props_roots_mut diverges from the sibling it claims to mirror. own_props.rs says it mirrors closure::dynamic_props "(same locked side table + GC root scanner contract)". The closure version does two things it does not: it falls back to forwarded_heap_owner(owner) when the visitor did not rewrite the key, and it re-inserts through merge_closure_prop_map so a post-rewrite key collision merges instead of clobbering. The buffer version does a bare props.insert(new_owner, entries).

Next

A Linux-side probe is running (diag/8117-probe, a manual-dispatch-only workflow that hammers just these two fixtures on ubuntu-latest and takes a gdb backtrace on the first signal), plus the same thing in a local Linux aarch64 container. Whatever the backtrace says, the three facts above stand: SIGSEGV, dating to #7314 on 2026-08-03, intermittent, and Linux-only.

[proggeramlug]

Root cause found. Both pass -> crash entries are one missing receiver arm — fix in #8141.

Correcting my own earlier comment on two points, both because I now have a Linux reproduction rather than an inference.

1. They DO reproduce standalone. "Passes standalone" was a property of my host.

host / mode	buffer_own_props	6386_dataview
macOS arm64, release, no auto-optimize, ×30	exit 0	exit 0
macOS arm64, auto-optimize	exit 0	exit 0
ubuntu 24.04 aarch64 container, no auto-optimize	exit 0 ×25	SIGSEGV 25/25
ubuntu 24.04 aarch64 container, auto-optimize	SIGSEGV	—
ubuntu-latest x86-64 (GitHub runner), no auto-optimize, standalone	SIGSEGV (139)	—

The x86-64 row is a manual-dispatch job on a clean checkout of fa83ecab2, compiling and running the fixture directly — no gap harness, no shard, no timeout wrapper. So this is not test isolation or ordering, and it is not the 7238/zlib class.

2. The bug

#0  js_array_length                                        <- SIGSEGV, x0 = 0x12b00003aa1f03e2
#1  perry_runtime::object::reflect_support::obj_value_has_own_key
#2  perry_runtime::proxy::own_set_descriptor
#3  perry_runtime::proxy::ordinary_set_with_receiver
#4  js_put_value_set
#5  js_put_value_set_dyn_ic_miss
#6  main

Faulting instruction ldurb w9, [x20, #-8], then cmp w9, #0x9 and a compare against 0x4C5A5841 — GC_TYPE_LAZY_ARRAY and LAZY_ARRAY_MAGIC. x0 is not an address.

obj_value_has_own_key has arms for a registry typed array, a GC_TYPE_ARRAY/GC_TYPE_LAZY_ARRAY, a closure and a native-module namespace — and none for a Buffer / ArrayBuffer / DataView. A buffer is a BufferHeader: no class_id, no keys_array. So the ordinary arm read (*obj).keys_array out of the bytes that follow a buffer header and handed it to js_array_length, with nothing in between but a < 0x10000 magnitude floor that payload bytes clear routinely.

Four lines, 10/10 on Linux:

const b: any = Buffer.alloc(8);
b.readUInt8 = function () { return "shadowed"; };
const k = "readUInt8";
b[k](0);

Same "ask the receiver question before the generic path claims it" shape as #8090 / #8109 / #8119 / #8120 — on the has-own-key / [[Set]] path this time. #8130 and #8140 are the same family again, which is starting to look like a category worth a sweep rather than one arm at a time.

3. Why the bisect landed on #7314, and why that was still worth doing

The defect is older than #7314. The garbage keys_array has to clear the floor and land unmapped; macOS's 2 TB heap floor makes it read as null, so the same call there silently answers "no own key" for a property the buffer really owns — wrong, but survivable.

#7314's one unconditional addition is initialize_stack_maps() in js_gc_init, whose Linux arm is std::fs::read("/proc/self/exe") — the entire executable into a heap Vec, before any user code, on every Perry binary. That moved the heap enough to turn a pre-existing wrong answer into a fault. So the bisect was correct about when it started landing and wrong about what is broken, which is exactly the failure mode a bisect on a layout-sensitive bug has. Reverting #7314 would not have fixed it.

(Independently worth a look: current main has widened that to loaded_stack_map_sections (#8075), which now std::fs::reads every dl_iterate_phdr image — the executable plus every shared object — at every Linux start.)

4. Fix and verification — #8141

A registered-buffer arm beside the typed-array arm, answering from the #6406 expando table. Prototype methods are inherited, not own, which is what lets buf.readUInt8 = fn install a shadowing own property; canonical integer indices are deliberately not folded in. Plus the keys_array guard becomes addr_class::is_plausible_heap_addr instead of the bare floor, as defence in depth for the next missing arm.

Linux container, before → after (grep -c "Compiling perry-runtime v" = 1 on the rebuild):

fixture	before	after
the 4-line repro	10/10 SIGSEGV	20/20 exit 0
test_gap_6386_dataview_concat_regex_fastpaths	25/25 SIGSEGV	20/20 exit 0
test_gap_buffer_own_props	SIGSEGV	20/20 exit 0

Both gap fixtures are byte-identical to node v26.5.1 afterwards. cargo test -p perry-runtime --lib → 2390 passed, 0 failed, 4 ignored (baseline 2389 + the new test). The test asserts the answer, not "did not crash", so it fails on macOS too — watched fail with the arm removed: "a buffer's own expando property must be reported as an own key".

Two side findings from the same read

• fix(gc): prune the buffer own-property table when its buffer dies #8136 — finalize_collected_dead_buffer prunes eleven address-keyed side tables and misses the buffer own-property table, so a dead buffer's expando closure is retained by the GC forever. Separate PR, sabotage-verified, explicitly not claimed as a fix for this issue.
• js_class_method_bind still binds a movable heap string's interior in four places #7747 missed (timer handles, TextDecoder/TextEncoder) #8133 — four js_class_method_bind sites still bind a movable heap string's interior (the siblings Fix a crash when reading a method off a Buffer without calling it #7747 missed: timer handles, TextDecoder.decode, TextEncoder.encode).

That leaves eight of the original twelve, and no crashes among them.

[proggeramlug]

Recount against current main (fb87d8923): 9 of the 12 now pass

Re-ran every one of the twelve pass -> X regressions on a fresh perry-dev build of current main, PERRY_NO_AUTO_OPTIMIZE=1, PERRY_RUNTIME_DIR pinned to that build's own .a files, byte-compared against node 26.5.1 (.node-version).

test	filed as	now
test_gap_6386_dataview_concat_regex_fastpaths	crash	pass
test_gap_7238_i64_specialization_exactness	crash	pass
test_gap_buffer_own_props	crash	pass
test_gap_zlib_4917_level	compile_fail	pass
test_gap_array_methods	parity_fail	pass
test_gap_builtin_alias_construct_7524	parity_fail	pass
test_gap_dynamic_builtin_construct_dispatch	parity_fail	pass
test_gap_new_globalthis_builtin_6726	parity_fail	pass
test_gap_specabi_reassign	parity_fail	pass
test_gap_collection_foreach_member_receiver_thisarg	parity_fail	parity_fail
test_gap_set_map_foreach_fused_receiver	parity_fail	parity_fail
test_gap_sso_concat_string_index	parity_fail	parity_fail

All three pass -> crash entries are gone. Two of them (buffer_own_props, 6386_dataview) were one bug — a missing Buffer/DataView arm in obj_value_has_own_key, fixed in #8141. specabi_reassign was #8100/#8109 as this issue predicted. The rest were cleared by the #8090/#8109/#8119/#8120/#8134/#8135 run.

This issue's own note that the twelve "are almost certainly main-side rather than any one PR's doing" was right, and it is the reason they cleared in a batch.

The three that remain

test_gap_collection_foreach_member_receiver_thisarg
  < set member no-thisArg: []
  > set member no-thisArg: ["n:10","n:20"]

test_gap_set_map_foreach_fused_receiver
  < [] 3                        > [10,11,12] 3
  <                             > a=1,b=2
  < [] 2                        > true true 1
  < [] 3                        > [1,2] 0

test_gap_sso_concat_string_index
  < undefined undefined undefined      > a b c
  < undefinedundefinedundefined        > abc
  < undefined undefined undefined      > % . "\n"

The first two are almost certainly one bug — Set/Map forEach with a member-expression callback or a fused receiver collects nothing. Note the second also loses whole output lines, so a callback is likely never invoked rather than merely returning empty.

The third is separate and the worst of the three: indexing a string returns undefined after an SSO concat. Silent wrong values, not a crash, and not confined to an exotic receiver.

All three are in flight.

Caveat on this measurement

My harness is a direct compile-and-cmp against node, not the gap runner. The real harness applies normalize_output, so a test I call parity_fail could normalize to a pass, and in principle the reverse. Treat the nine as "very likely clear" and confirm on the next full conformance-smoke run rather than closing this issue on my numbers alone. I would rather state that than have someone close it and find the gate still red.

The 10 node_fail -> parity_fail entries are untouched by this recount — they were always broken and still need triaging into test-parity/gap_snapshot.json with issue links, as this issue's step 1 says.