Skip to content

daemon: shutdown waits for a handshake poll in flight; follow-ups to #500 - #514

Merged
TeoSlayer merged 2 commits into
mainfrom
fix/handshake-poll-followups
Oct 7, 2026
Merged

TeoSlayer merged 2 commits into
mainfrom
fix/handshake-poll-followups

Conversation

@TeoSlayer

Copy link
Copy Markdown
Collaborator

Follow-ups from the second independent review of #500 (merged in v1.16.0). All low severity; none changes the trust timings.

Changes

  • Shutdown waits for a poll in flight. The registry empties a node's handshake inbox as it answers a poll. doStop closed the registry client without waiting for a poll that was still running, so a restart during one dropped the requests and approvals it carried (the reviewer reproduced it with a 1 s reply and a stop 200 ms into the poll). doStop now waits up to 5 s (waitIdle) before closing the client, and pollHandshakes starts nothing once the daemon is stopping.
  • The full peer table evicts one entry, not all of them. At the 64-peer cap, only the closed-window peer whose rearm ends soonest is dropped. The others keep their hold-off, so an application redialling many unanswering peers cannot keep reopening fast polling.
  • A notify with extra bytes after the handshake kind is acted on. A later beacon can then extend the message without older daemons ignoring it. A bare type byte and unknown kinds are still dropped.
  • Comments: the package doc states the wait-for-trust condition, and pollRelayedHandshakes no longer documents the removed timeout.

Tests

  • New: TestShutdownWaitsForThePollInFlight.
  • Extended: TestSettledPeersDoNotCrowdOutANewRequest (only one entry is evicted) and TestBeaconNotifyOfUnknownKindIsDropped (trailing bytes after a known kind are accepted).
  • go vet is clean. The pkg/daemon unit suite passes, and the handshake-poll tests pass twice under -race.

🤖 Generated with Claude Code

Teo Calin and others added 2 commits October 7, 2026 17:08
…-ups to #500

From the second review of #500.

- Shutdown closed the registry client without waiting for a poll in
  flight. The registry empties the node's handshake inbox as it answers,
  so a restart during a poll lost what it carried. doStop now waits up to
  5s for the poll (waitIdle), and pollHandshakes starts none once the
  daemon is stopping.
- At the 64-peer cap, only the closed-window peer whose rearm ends
  soonest is evicted; the others keep their hold-off against automatic
  handshakes reopening a window.
- A beacon notify with bytes after the handshake kind is acted on, so a
  later beacon can extend the message without older daemons ignoring it.
- Comments: the package doc describes the wait-for-trust condition, and
  pollRelayedHandshakes no longer documents the removed timeout.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review fixes.

- Shutdown waited for a poll in flight only after the handshake manager had
  stopped, so the poll's reply was processed by a stopped manager: requests
  and approvals were neither saved nor answered, and the registry had
  already emptied the inbox. The wait now comes before the manager stops.
- No poll can start once shutdown has begun: the scheduler is closed under
  the same lock that starting a poll takes. Before, a caller past the
  stopping check could start one after the wait had returned.
- The wait shares the 5s deadline shutdown already gives its background
  goroutines instead of adding 5s of its own.
- The shutdown test now calls Stop and checks the order; tests cover the
  closed scheduler and which settled peer is let go. Each fails against
  the matching revert.
- Changelog entries for the eviction and notify changes; the notify
  comments say v1.16.0 still requires exactly two bytes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@TeoSlayer
TeoSlayer force-pushed the fix/handshake-poll-followups branch from 14dbf88 to eb67eba Compare October 7, 2026 14:08
@TeoSlayer
TeoSlayer merged commit abffeb7 into main Oct 7, 2026
14 checks passed
@TeoSlayer
TeoSlayer deleted the fix/handshake-poll-followups branch October 7, 2026 14:24
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