Summary
During SPV sync, dash_spv emits a large volume of per-packet and per-batch messages at DEBUG level. These flood the log file and make it hard to extract meaningful diagnostics. They should be TRACE since they represent internal network I/O and tight-loop state — useful only when debugging the SPV stack itself.
Observed in a single ~10-minute sync session against Testnet (3 peers):
| Message |
Current level |
Occurrences |
Recommended |
network::manager: Received "cfilter" from <peer> |
DEBUG |
~1.5M |
TRACE — raw per-packet I/O |
network::manager: Request processor: sending getcfilters |
DEBUG |
1 516 |
TRACE — internal dispatch detail |
network::manager: Distributing getcfilters request to peer |
DEBUG |
~1 500 |
TRACE — per-peer copy of above |
network::manager: Request processor: sending getcfheaders |
DEBUG |
762 |
TRACE |
network::manager: Distributing getcfheaders request to peer |
DEBUG |
757 |
TRACE |
network::manager: Received "cfheaders" from <peer> |
DEBUG |
756 |
TRACE |
network::manager: Request processor: sending getdata |
DEBUG |
319 |
TRACE |
network::manager: Request processor: sending getheaders |
DEBUG |
282 |
TRACE |
sync::filters::manager: scan_batch: no behind wallets with monitored addresses |
DEBUG |
312 |
TRACE — tight-loop internal state |
validation::filter: Verified 1000 filters successfully |
DEBUG |
1 505 |
TRACE or throttle (fires per-batch) |
Additional finding — SyncProgress log message is empty
client::event_handler: SyncProgress: fires at INFO level 2 210 times with an empty body — the progress value is not being formatted into the message. The format string appears to be missing {}, or the value does not implement Display. This should be fixed to include the actual progress (e.g., percentage or block height), or downgraded to TRACE if the structured event is the intended signal.
Impact
At DEBUG log level, a 10-minute sync produces millions of lines of noise, making the log file effectively unsearchable for real warnings and errors. Downgrading these to TRACE keeps DEBUG usable for day-to-day diagnostics.
Summary
During SPV sync,
dash_spvemits a large volume of per-packet and per-batch messages atDEBUGlevel. These flood the log file and make it hard to extract meaningful diagnostics. They should beTRACEsince they represent internal network I/O and tight-loop state — useful only when debugging the SPV stack itself.Observed in a single ~10-minute sync session against Testnet (3 peers):
network::manager: Received "cfilter" from <peer>network::manager: Request processor: sending getcfiltersnetwork::manager: Distributing getcfilters request to peernetwork::manager: Request processor: sending getcfheadersnetwork::manager: Distributing getcfheaders request to peernetwork::manager: Received "cfheaders" from <peer>network::manager: Request processor: sending getdatanetwork::manager: Request processor: sending getheaderssync::filters::manager: scan_batch: no behind wallets with monitored addressesvalidation::filter: Verified 1000 filters successfullyAdditional finding —
SyncProgresslog message is emptyclient::event_handler: SyncProgress:fires at INFO level 2 210 times with an empty body — the progress value is not being formatted into the message. The format string appears to be missing{}, or the value does not implementDisplay. This should be fixed to include the actual progress (e.g., percentage or block height), or downgraded to TRACE if the structured event is the intended signal.Impact
At
DEBUGlog level, a 10-minute sync produces millions of lines of noise, making the log file effectively unsearchable for real warnings and errors. Downgrading these toTRACEkeepsDEBUGusable for day-to-day diagnostics.