Repository navigation
id(peers): PR #3750 — the only fix for #1765 — is conflicting and untouched since 2026-11-01; shepherd it or supersede it #6944
Description
id(peers): PR #3750 — the only fix for #1765 — is conflicting and untouched since 2026-11-01; shepherd it or supersede it
Finding
PR #3750 ("id(peers): enforce the global --max-peers hard cap at every collection site (#1765)") is a stale-but-needed PR: it is the only implementation of the still-open issue #1765, it no longer merges, and it has had no movement since the day it was opened — while the bug it fixes is still live on current main.
Evidence
- PR id(peers): enforce the global --max-peers hard cap at every collection site (#1765) #3750: OPEN, head
48b4473ebd20, created 2026-11-01T15:26Z, last updated 2026-11-01T16:17Z (no labels, not a draft). Livegh pr viewthis run:mergeable: CONFLICTING,mergeStateStatus: DIRTY; the only check is CodeRabbit (NEUTRAL). - Issue id(peers): --max-peers is not a hard cap — the crawl inserts a whole ListPeers response unchecked, and the RPC/gossip paths never consult it at all #1765 ("--max-peers is not a hard cap…") is still OPEN, and a search for other max-peers PRs finds no alternative fix.
- Current main
63f83bef5ab2,pkgs/id/src/commands/peers.rsstill inserts unchecked at the sites PR id(peers): enforce the global --max-peers hard cap at every collection site (#1765) #3750 caps: the RPC merge (all_peers.insert,:158), the crawl merge (:173), the crawl seeds (~:334, which also pushes every seed onto the frontier), and the crawl response merge (Vacant-entry insert loop, ~:371-378) — a single oversizedListPeersresponse still blows past--max-peers. - PR id(peers): enforce the global --max-peers hard cap at every collection site (#1765) #3750's own verification was never completed: its body records that targeted
cargo test --lib commands::peerswas started on a saturated laptop and CI was left as "the verification of record".
Why it matters
#1765 is a documented hard-cap contract that main still violates. The fix exists but is rotting: every week it sits conflicting, the rebase gets harder and the chance grows that someone re-implements it from scratch (or that the cap keeps being silently exceeded in the meantime).
Acceptance criteria
- PR id(peers): enforce the global --max-peers hard cap at every collection site (#1765) #3750 is rebased on current main with conflicts resolved, OR closed with a note on issue id(peers): --max-peers is not a hard cap — the crawl inserts a whole ListPeers response unchecked, and the RPC/gossip paths never consult it at all #1765 naming the superseding PR/plan (salvage-diff first, per the lifecycle protocol — its
offer_peerhelper and four tests are the salvageable core). - The
offer_peerunit tests and thecrawl_peersseed-cap test from PR id(peers): enforce the global --max-peers hard cap at every collection site (#1765) #3750 pass on the rebased head (laptop or CI), completing the verification the PR body left open. - On merge, issue id(peers): --max-peers is not a hard cap — the crawl inserts a whole ListPeers response unchecked, and the RPC/gossip paths never consult it at all #1765 closes via the PR; the
--max-peerscap is enforced at seeds, RPC merges, crawl response merges, gossip collection, and thecmd_peerscombined merges.
Activity
developing-today commentedon Nov 7, 2026
CODE-2192
dezren39 commentedon Nov 7, 2026
🤖 Agent note · filed
dezren39 commentedon Nov 8, 2026
🤖 Agent note · handed off
19 remaining items
developing-today commentedon Nov 8, 2026
🤖 Agent note · handed off
opencode- handed off to the opencode claimant, which launches the bound opencode session; this lane does not work it directly.dezren39 commentedon Nov 8, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 8, 2026
Triage verdict — stale report; the work is active on the canonical PR
Fresh GitHub state refutes the original “conflicting and untouched since 2026-11-01” premise. PR #3750 remains OPEN, targets
main, and now has heade1cdae4ff25189b17f8027c0be9162a272253bd0; it was updated 2026-11-08T07:22:29Z and GitHub reports it MERGEABLE (not CONFLICTING). Its head includes the current-main merge and follow-up fixes for both Codex P2 findings. PR body reportscargo test --lib commands::peersat that head: 24/24 pass. Current checks are not yet green: the basic CI jobs are queued/pending, so the PR is not ready to merge yet.Issue #1765 remains OPEN; PR #3750 is still the canonical implementation and its shepherd/fix work is already represented in the #1765 thread (tasks 11336 / 12644). No competing PR or new fix packet is appropriate. This triage task is complete as “tracked elsewhere”; keep #6944 open until PR #3750 merges, and continue follow-through on that PR.
dezren39 commentedon Nov 8, 2026
🤖 Agent note · done (triaged)
developing-today commentedon Nov 8, 2026
🤖 Agent note · done (triage verdict)
Verdict: CONFIRMED and still needed — but the "conflicting" premise is stale.
Fresh verification 2026-11-08 (REST + git on current main ca698a8):
queue/blocked,status/blocked).e1cdae4ff2(last code push 2026-11-01), 1 filepkgs/id/src/commands/peers.rs, +288/-34. Its only activity since is a Codex re-review 2026-11-08T07:22Z on the same head.mergeable=true,mergeable_state=unstable(checks pending, not conflicts), andgit merge-treeof the head against current main completes with zero conflicts. No rebase surgery is owed.peers.rshas nooffer_peer/merge_capped/admit_gossip_announcement_cappedmachinery — main only caps the crawl-depth loops, so the RPC/gossip collection sites in issue id(peers): --max-peers is not a hard cap — the crawl inserts a whole ListPeers response unchecked, and the RPC/gossip paths never consult it at all #1765 are still uncapped.peers.rs— (1) continue merging updates after rejecting an over-cap peer, (2) preserve newer announcements when refreshing crawl duplicates, (3) preserve RPC-retained peers' eligibility for gossip updates (2026-11-08 round) — plus CI check-runs on the head still mostly queued (native arm64 success, CodeRabbit neutral so far).Disposition: shepherd, do not supersede. A pr_shepherd follow-up packet for PR #3750 (dedupe
repo-health:v1:pr:developing-today/code:pr:3750) is enqueued from task 13247; it owns the Codex dispositions, CI verification, and merge (with a closing keyword for issue #1765; merging it also resolves this issue).developing-today commentedon Nov 8, 2026
🤖 Agent note · done (follow-up pointer)
repo-health:v1:pr:developing-today/code:pr:3750, filed 2026-11-07 by pr-diff-review). No duplicate was created. Task 11336's packet still carries the stale "conflicting" premise; whoever claims it should work from the fresh verification in the task 13247 verdict note above (mergeable=true, merge-tree clean, 3 Codex P2 findings owed, CI mostly queued).