#35600 net: prevent duplication manual connections (take 2)

ReviewabilityReviewsAgreementSize
#35600 willcl-ark net: prevent duplication manual connections (take 2)Ready0 (+1)Strong47 + 118 tests
  • Prevent duplicate manual outbound P2P connections caused by racing startup options or concurrent addnode calls
  • Fixes a long-standing issue where in-flight connection attempts bypass duplicate checks before completing
  • Ready to review
  • Author accepted a cleanup suggestion that has not yet been pushed
  • Strong substantive support with no blocking objections
  • Verified by running functional suite, net unit tests, and checking failure modes (8144225309)
  • Concept approval without stated reasons (sedited, w0xlt)
  • Nonblocking suggestion to test addconnection during an in-flight manual connection (8144225309)
  • 47 lines added or modified outside tests
  • 118 lines added or modified in tests
  • 1 lines removed in total
  • 4 files, 2 commits
P2P#42 of 71
P3 · bug fix
  • P3 because it resolves an edge-case bug where racing manual connection attempts open duplicate connections
  • Prevents redundant outgoing connections during startup or concurrent addnode invocations
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Tracks in-flight manual P2P connection attempts in `CConnman` using a set of pending destination keys to prevent duplicate connections. When `OpenNetworkConnection()` initiates a manual connection, it registers the target in `m_manual_connection_in_progress` and clears it upon exit using an RAII guard. Concurrent attempts to dial the same numeric address or raw hostname string are rejected while the first attempt is pending.

Problem: Concurrent manual connection attempts to the same target—such as overlapping `-connect` and `-addnode` startup arguments or concurrent `addnode onetry` invocations—race past existing duplicate checks. Because existing checks only verify connected peers already present in `m_nodes`, multiple connections to the same remote peer can be established before either completes.

Evidence of importance:

  • PR description fixes #5299, an open issue titled 'Initial connection management' dating back to 2014.
  • PR description: '-connect and -addnode can attempt the same manual connection concurrently during startup. The existing duplicate checks cannot see a peer until it has been added to m_nodes, so both attempts can pass and open connections.'

Risk of a mistake: low (p2p). A flaw in reservation tracking could incorrectly block manual outbound connections or trigger an assert on unexpected connection state.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • author: push the accepted change and respond to test suggestion 2026-10-05

Agreement

Strong

substantive support, no open objection (8144225309)

Thread notes: Author replied to maflcko's inline suggestion accepting it.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
8144225309 (contributor)suggestion, maintenanceAdd a test case with addconnection to the same destination during a manual connection attemptopenansweredno2026-10-04: 'The test still passes if the reservation covers every connection type (net.cpp:3139). An `addconnection` to the same destination while a manual attempt is in progress would catch that. Non-blocking.'
maflcko (member)suggestion, approachDrop them as suggested by ralphanswered · author accepted the suggestionansweredyes2026-10-04: 'ralph says to drop them, which seems right?'
Status from: 2026-10-05: willcl-ark: 'Good bot. Taken.'

Support:

  • sedited (member) (Concept ACK, 2026-07-24): (no reason given) [not substantive]
  • w0xlt (contributor) (Concept ACK, 2026-08-18): (no reason given) [not substantive]
  • 8144225309 (contributor) (ACK, 2026-10-04) [tested]: Built and ran the new test, functional suite, and net unit tests; verified failure modes

Participants:

  • sedited (member, support, 1 statements 2026-07-24 to 2026-07-24): Concept ACK
  • w0xlt (contributor, support, 1 statements 2026-08-18 to 2026-08-18): Concept ACK
  • 8144225309 (contributor, support, 1 statements 2026-10-04 to 2026-10-04): ACK with testing notes and non-blocking test suggestion
  • maflcko (member, question, 1 statements 2026-10-04 to 2026-10-04): suggested dropping them per ralph's comment

Files

118 lines under test/bench/ci.

  • test/functional/p2p_duplicate_manual_connections.py +117/-0
  • src/net.cpp +41/-1
  • src/net.h +6/-0
  • test/functional/test_runner.py +1/-0

Card

The short text the ranking pass compares across PRs.

Tracks in-flight manual P2P connection attempts in CConnman to prevent duplicate connections to the same target. Concurrent manual connection attempts—such as -connect and -addnode specifying the same destination during startup—race past existing duplicate checks because those checks only inspect peers already added to m_nodes. Target addresses and hostnames are now reserved during OpenNetworkConnection() so concurrent attempts are rejected while a dial is pending. This addresses long-standing issue #5299 with a functional test exercising concurrent attempts via a proxy handshake.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-07T01:11, confidence high, input hash 0d550f1198a168b2
thread read through 2026-10-05 (5 statements), head 590947d783
labels: P2P

Categories

P2P

P3 · bug fix

Prevents redundant outgoing connections when manual connection attempts race before entering m_nodes. Existing duplicate checks cannot see in-flight connections during startup or concurrent addnode calls (fixing #5299), resolving an edge-case connection management bug without posing broader stability risks.

Membership: Changes manual connection logic in src/net.cpp and src/net.h to avoid duplicate connections.

Factors: security/stability 1, bug 1, performance 0, user value 1, leverage 0