fix(ext-net): give the pump's in-flight dispatch GC custody (#8259)

[proggeramlug]

Fixes #8259.

Root cause

Every arm of js_ext_net_drain_pending snapshotted its listeners into a bare Vec<i64> (listeners_for) and, for some arms, allocated a payload (alloc_buffer / alloc_string / build_error_object) before the call loop. Both steps can collect — the allocation directly, every call* by running arbitrary user JS — and the evacuating arms then move the closures: scan_net_roots rewrites the canonical statics::listeners() slots, but a bare local snapshot is invisible to it, so callback N (and the already-built payload) were dereferenced at their old addresses once callback N−1's JS forced a collection. The #8259 witness's once('data') handler churns 30k objects between the two 'data' callbacks — deterministic by construction.

ServerListening/ServerClose were worse: they remove their callbacks from the table before firing (one-shot semantics), so during dispatch nothing rooted them at all — a full sweep could free, not just move, them.

Not a regression from #8216 — its scanner fix is correct; its witness (which had never completed a CI run: the PR's own gc-stress was cancelled in the queue saturation) was the first thing to ever execute this path under forced evacuation.

Fix

The same custody pattern #8216 introduced for ext-http's H2 pump: park the snapshot (+ at most one NaN-boxed payload per frame) in scanned thread-locals (dispatch_custody.rs), re-read each slot immediately before use so the copying GC's rewrite is observed, pop on drop (RAII, nests for re-entrant pumps). All ten dispatch loops converted. scan_net_roots visits the custody stacks; the root-holder census certifies the new holders through that call path.

Validation

• A/B under the matrix's exact force_verify env (PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1), same freshly built release compiler, auto-opt archive cache wiped between arms:
  • pre-fix: rc=1, TypeError: value is not a function (macOS spelling of the Linux SIGSEGV — same stale-closure deref), stdout empty
  • post-fix: rc=0, once fired: 1 of 2 events (byte-correct vs node)
  • copying minors live in both arms (6 copy-minor records under the matrix env; not a vacuous pass)
• 3 new unit tests on the custody frame (nesting, rewrite-visibility — the property the parking exists for — and empty frames); cargo test -p perry-ext-net otherwise unchanged (the one pre-existing macOS-host relocation-expectation failure fails identically pre/post-fix and passes on CI Linux)
• gc_runtime_root_holders.py and check_thread_locals.py both green with no inventory edits — the census reaches the new holders via the registered scanner
• cargo fmt --check clean

Once merged, gc-stress (which reds pr-gate on every rebased PR via this cell today) goes back to green; PR #8244's failure was this.

[coderabbitai]

Warning

Review limit reached

@proggeramlug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

Limit details: You’ve used all 8 included reviews currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e5f615d2-c5aa-40b7-82da-1630064d3cc3

📥 Commits

Reviewing files that changed from the base of the PR and between cc7a546 and c385425.

📒 Files selected for processing (3)

• changelog.d/8265-net-dispatch-custody.md
• crates/perry-ext-net/src/dispatch_custody.rs
• crates/perry-ext-net/src/lib.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[proggeramlug]

Merging. This is the most carefully evidenced GC PR I've reviewed today — a few notes on what I verified independently rather than took on trust.

The "not a vacuous pass" line is the part that matters, and it is the check most GC PRs skip. Six copy-minor records under the matrix env means the fix was actually exercised, not merely un-crashed; a green arm that ran zero copying minors would have proven nothing. Same for the pre-fix arm reproducing rc=1, TypeError: value is not a function — a fix without a demonstrated red baseline is unfalsifiable.

The one failing test is genuinely pre-existing. I did not take that on trust: reverting lib.rs to origin/main and deleting dispatch_custody.rs, tests::gc_mutable_scanner_rewrites_listener_roots still fails on this macOS host. So it is the host relocation-expectation failure you described, not something this PR introduced.

Verified here: perry-ext-net 27 passed / 1 failed (that one), all three new custody tests present and passing (parked_slots_are_the_read_path, frames_nest_and_pop, empty_frame_is_cheap_and_safe), and gc_runtime_root_holders, check_thread_locals, addr_class_inventory, check_file_size and cargo fmt all clean. parked_slots_are_the_read_path is the right test to have written — it pins the rewrite-visibility property the parking exists for, rather than just that the frame nests.

One fix pushed: the changelog fragment was named 8260-net-dispatch-custody.md. Fragment filenames are PR-keyed precisely so in-flight PRs never collide, and #8260 is a different, unrelated PR. Renamed to 8265-.

One note on my side, not yours. #8253 added scripts/unrooted_local_shape.py, which is meant to catch exactly this class in perry-ext-*. It reports 218 findings both before and after this PR — it does not see the bug you fixed. Its detector matches let x = js_*_alloc(...) bindings, so a Vec<i64> snapshot of listener pointers is invisible to it. That is a real blind spot in my instrument, and this PR is the counter-example that proves it; I'll extend it to container-of-pointer snapshots.