🐞 Bug Report
Description
PeersFromStringAddrs returns on the first entry that fails to parse, discarding the entire list rather than the one bad entry. A single malformed --peer (static/trusted peer) value therefore drops all of the others.
Where
beacon-chain/p2p/discovery.go, PeersFromStringAddrs (~lines 775-797): both the enode.Parse and retrieveMultiAddrsFromNode error paths do return nil, err, so one failure aborts the whole loop. The caller in Start() then logs and proceeds with an empty list.
parseGenericAddrs already pre-filters unparseable entries, so the realistic trigger is narrow — an entry that parses as an enode/ENR but yields no usable multiaddr (e.g. no tcp endpoint) — but when it happens, every other configured peer is silently lost.
Has this worked before in a previous version?
No — long-standing behavior.
🔬 Minimal Reproduction
Start a node with two --peer values where the first is a valid-format enode that yields no dialable multiaddr and the second is a good peer; neither is added.
Note
Filing as an issue rather than a PR because the fix changes error-handling semantics for user-supplied config (failing loud on a bad --peer may be intended), and the trigger is narrow — a maintainer call on skip-and-warn vs fail-fast would be good before a patch. Found during a cross-client discv5 audit.
🐞 Bug Report
Description
PeersFromStringAddrsreturns on the first entry that fails to parse, discarding the entire list rather than the one bad entry. A single malformed--peer(static/trusted peer) value therefore drops all of the others.Where
beacon-chain/p2p/discovery.go,PeersFromStringAddrs(~lines 775-797): both theenode.ParseandretrieveMultiAddrsFromNodeerror paths doreturn nil, err, so one failure aborts the whole loop. The caller inStart()then logs and proceeds with an empty list.parseGenericAddrsalready pre-filters unparseable entries, so the realistic trigger is narrow — an entry that parses as an enode/ENR but yields no usable multiaddr (e.g. no tcp endpoint) — but when it happens, every other configured peer is silently lost.Has this worked before in a previous version?
No — long-standing behavior.
🔬 Minimal Reproduction
Start a node with two
--peervalues where the first is a valid-format enode that yields no dialable multiaddr and the second is a good peer; neither is added.Note
Filing as an issue rather than a PR because the fix changes error-handling semantics for user-supplied config (failing loud on a bad
--peermay be intended), and the trigger is narrow — a maintainer call on skip-and-warn vs fail-fast would be good before a patch. Found during a cross-client discv5 audit.