server: document peerLifecycle channel buffer sizing
What changed, and why it matters
This commit only adds a comment explaining why a channel buffer is sized a certain way. No code behavior changes, so there is no security issue or fix here.
No action needed; this is a non-functional documentation-only change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff is purely documentation: it inserts an inline comment in server.go explaining that the peerLifecycle channel is buffered to cfg.MaxPeers*2 because each peer can generate two lifecycle events (peerAdd and peerDone). The actual make(…) call and all surrounding code remain identical. There are no functional changes, no bug fixes, and no security-relevant modifications.
Changed components
server.go peerLifecycle channel buffer documentationInspect captured patch +8 / −3
diff --git a/server.go b/server.go
index a9268cb..33f548c 100644
--- a/server.go
+++ b/server.go
@@ -2903,9 +2903,14 @@ func newServer(listenAddrs, agentBlacklist, agentWhitelist []string,
}
s := server{
- chainParams: chainParams,
- addrManager: amgr,
- peerLifecycle: make(chan peerLifecycleEvent, cfg.MaxPeers*2),
+ chainParams: chainParams,
+ addrManager: amgr,
+
+ // peerLifecycle is buffered for up to two events per peer
+ // (peerAdd followed by peerDone) so peerLifecycleHandler
+ // does not block under normal connect/disconnect churn.
+ peerLifecycle: make(chan peerLifecycleEvent, cfg.MaxPeers*2),
+
banPeers: make(chan *serverPeer, cfg.MaxPeers),
query: make(chan interface{}),
relayInv: make(chan relayMsg, cfg.MaxPeers),
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.