logs: spamming of "SPV: Peering attempt failed"

[norwnd]

I was looking into decred/dcrdex#3000 - looking into dcrwallet neutrino logs I've noticed there is a lot of lines similar to this one being logged (here is a .gz snapshot neutrino saves as an example):

2024-10-11 11:49:44.308 [WRN] SPV: Peering attempt failed: localpeer.ConnectOutbound([2a01:4f9:c012:ceaf::1]:9108): dial tcp [2a01:4f9:c012:ceaf::1]:9108: connect: no route to host
2024-10-11 11:49:44.309 [WRN] SPV: Peering attempt failed: localpeer.ConnectOutbound(51.79.173.96:9108): dial tcp 51.79.173.96:9108: connect: network is unreachable

Couple of points on this:

• at the very least, logging that statement that often is leading to "useful" logs being rotated out (plus it's unnecessary resources waste, might even contribute to high CPU usage (on Mac) after network disconnect dcrdex#3017)
• but also can potentially signal some deeper underlying issue with how networking is handled

To reproduce: I was running dexc, shut my laptop lid + disconnecting internet cable, re-opened it several hours later + reconnected internet cable (and ended up observing decred/dcrdex#3000 + this spam in dcrwallet logs) just plug off internet cable for several minutes and watch logs grow.

[jrick]

This isn't really a log spam problem as it is a connection logic problem.

You have no routes to reach these peers, so all connection attempts immediately fail while the wallet is trying to achieve 8 outbound peers.

(also, we don't use neutrino)

[norwnd]

(also, we don't use neutrino)

Is this dex-specific then ? In that case probably want to move this issue to https://github.com/decred/dcrdex/issues

[jrick]

dcrwallet has its own spv implementation. it doesn't have any special name or branding or anything. neutrino is the name of a different implementation used by btcwallet (but afaik, they are broadly similar in terms of how they work and the filters that they use).

[norwnd]

Well, the log files written by Bison Wallet are called neutrino... so I'm just calling those as they are,

the connection attempts that result in these logs still happen somewhere in dcrwallet codebase right ? To my understanding, there should be a delay between retries:

• to not write so many logs
• to not overwhelm peers with requests (if that can be a problem)