Skip to content

p2p: count pending static dials toward the dial demand - #1017

Open
hyunsooda wants to merge 1 commit into
kaiachain:devfrom
hyunsooda:fix/count-static-dials-in-dial-demand
Open

p2p: count pending static dials toward the dial demand#1017
hyunsooda wants to merge 1 commit into
kaiachain:devfrom
hyunsooda:fix/count-static-dials-in-dial-demand

Conversation

@hyunsooda

@hyunsooda hyunsooda commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Proposed changes

getCandidates computes the dynamic dial demand before appending the static
nodes, so statics dialed in the same batch go uncounted and the outbound count
for their type settles at target + statics. The demand now drops by every
static about to be dialed.

Types of changes

  • 🐛 Bug fix
  • ✨ Non-hardfork changes (node upgrade not required)

Checklist

  • 📖 I have read the CONTRIBUTING GUIDELINES doc
  • 🟢 Lint and unit tests pass locally with my changes ($ make test)

Further comments

Only statics passing dialEligible are subtracted — connected or dialing ones
already sit in the counts. shouldDial was split so that check can run under
the read lock getCandidates already holds.

getCandidates derived the dynamic demand from the connected and dialing counts,
then appended the static nodes without touching that demand, so statics dialed
in the same batch were invisible to it and the outbound count for their type
settled at the target plus the number of statics of that type. Nothing trims the
excess afterwards, and a warm discovery table on restart is enough to reach it.
The demand now drops by every static that is about to be dialed, which is what
the function comment already claims: you don't need dynamic candidates when you
have enough static nodes.

Constraint: the subtraction runs under the read lock getCandidates already holds, so shouldDial was split into a lock-free dialEligible rather than re-entering the lock
Constraint: only statics passing dialEligible are subtracted; connected or dialing ones are already in the counts that produced the demand
Rejected: Make the dynamic dial reservation atomic | dialLoop is a single goroutine running getCandidates and launchDialTasks in sequence, so there is no window to close
Confidence: high
Scope-risk: narrow
Not-tested: a dead static delaying its dynamic replacement by one dial timeout

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@hyunsooda hyunsooda self-assigned this Aug 6, 2026
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