Skip to content

feat(peer): register accepted inbound peers in the connected pool (#3124) - #402

Draft
MichaelTaylor3d wants to merge 1 commit into
mainfrom
loop/3124-inbound-adoption
Draft

feat(peer): register accepted inbound peers in the connected pool (#3124)#402
MichaelTaylor3d wants to merge 1 commit into
mainfrom
loop/3124-inbound-adoption

Conversation

@MichaelTaylor3d

Copy link
Copy Markdown
Contributor

DO NOT MERGE — WIP, gate round not yet run, and BLOCKED on a dependency.

Consumer half of dig_ecosystem#3124 — https://github.com/DIG-Network/dig_ecosystem/issues/3124

Depends on DIG-Network/dig-gossip#83, which adds the entry point this PR calls.

What

serve_peer_rpc_listener_with accepted, authenticated and served every inbound peer while registering
none of them, so connected_peers under-reported every one. It now adopts each accepted connection
into the dig-gossip pool for the life of its serve loop, and releases the slot when that loop returns.

BLOCKER — the rev pin is temporary

crates/dig-node-core/Cargo.toml currently pins dig-gossip to this lane's BRANCH commit
(f21f993) so the wiring could be compiled and proven. It must be re-pinned to dig-gossip main
after #83 merges, before this leaves draft.

dig-gossip is not published on crates.io (index.crates.io → 404), so a version dependency is not
available today; the git = pin is pre-existing (NC-7 / CLAUDE.md §3.6) and this PR does not resolve
it. Flagged for the orchestrator rather than fixed here — a first publish of the crate is irreversible
and well outside this ticket.

Status

  • listener wiring, both call sites
  • tests
  • re-pin to dig-gossip main
  • version bump

Blast radius: to be stated before this leaves draft.

…124)

dig-node's mTLS peer-RPC listener accepted, authenticated and served inbound
peers while registering none of them, so `connected_peers` under-reported
every inbound peer. It now adopts each accepted connection through
dig-gossip's direct-inbound entry point for the life of its serve loop, and
stops counting it when that loop returns.

Registers BY HANDLE: the serve loop needs `&mut PeerSession`, so handing the
session to the pool would buy the count and stop serving the peer.

Adoption is best-effort -- a pool refusal is an accounting decision and never
a reason to refuse service to a peer whose handshake already succeeded.

Refs: DIG-Network/dig_ecosystem#3124

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant