SPV request processor sends getcfheaders/getqrinfo to peers that don't support them

[lklimek]

Summary

The SPV request processor dispatches getcfheaders and getqrinfo messages to connected peers without checking if they advertise the required service bits (e.g. NODE_COMPACT_FILTERS). When no connected peer supports the capability, the request fails with:

ERROR Request processor: failed to send message: Protocol error: No peers support required capability

The request then times out after 20s and retries — hitting the same error repeatedly until a capable peer eventually connects.

Steps to Reproduce

1. Start SPV sync on testnet with DNS seed discovery
2. Connect to 1-3 peers (typical initial connection count)
3. Observe logs during compact filter header sync phase

Observed behavior

DEBUG Sent GetCFHeaders: start=1450281, stop=0000008b... (1 active, 0 pending)
DEBUG Request processor: sending getcfheaders
ERROR Request processor: failed to send message: Protocol error: No peers support required capability
# 20s later...
DEBUG 1 items timed out after 20s
DEBUG Sent GetCFHeaders: start=1450281, stop=0000008b... (1 active, 0 pending)
DEBUG Request processor: sending getcfheaders
ERROR Request processor: failed to send message: Protocol error: No peers support required capability

This repeats every 20s until a capable peer connects (observed 5+ cycles in testing).

Also affects getqrinfo:

DEBUG Request processor: sending getqrinfo
ERROR Request processor: failed to send message: Protocol error: No peers support required capability

Expected behavior

1. The request processor should check peer capabilities before dispatching and only send to peers that advertise the required service bits
2. If no capable peer is currently connected, the request should be queued (not failed) and dispatched when a capable peer connects
3. The log level should be WARN or DEBUG, not ERROR — this is a transient condition, not a fatal failure

Impact

• Sync stalls: Compact filter sync and quorum rotation queries are blocked until a capable peer connects
• Log noise: ERROR-level log spam every 20s during the stall
• Test flakiness: In automated testing, the stall contributes to timeout failures

Environment

• dash-spv from dashpay/rust-dashcore (observed on multiple revisions including v0.42-dev)
• Testnet with DNS seed discovery
• Typically 1-3 initial peers

_{🤖 Co-authored by Claudius the Magnificent AI Agent}