rescanblockchain/loaddescriptor silently drop matched blocks when the block fetch fails

[jvsena42]

Description

In rescan_with_block_filters (crates/floresta-node/src/json_rpc/server.rs, ~L616) matched blocks are downloaded with:

for block in blocks {
    if let Ok(Some(block)) = node.get_block(block).await {
        let height = chain.get_block_height(&block.block_hash()).unwrap().unwrap();
        wallet.block_process(&block, height);
    }
}

NodeInterface::get_block resolves three ways: Ok(Some), Ok(None) (peer replied NOTFOUND), and Err(RecvError) (responder dropped — e.g. MAX_INFLIGHT_REQUESTS reached or peer disconnected). The if let Ok(Some(..)) silently discards the latter two, so a matched block that momentarily fails to download is dropped from the rescan and never retried — the wallet permanently misses the transactions it carried, even though the rescan reports success.

Impact

On bandwidth/peer-constrained setups (notably the Android port, jvsena42/mandacaru#81) users see wallet history missing transactions after a "successful" rescan and must re-run rescanblockchain many times — each pass logs a different set of rescan filter hits as different blocks happen to succeed.

Suggested fix

Retry failed fetches (bounded, with backoff) so one rescan processes every matched block; surface a count of any blocks still unreachable after the cap. Reference implementation: jvsena42/Floresta-mandacaru#17.

Note: the reference PR targets a fork ~1 month behind master, so it may need light adaptation (e.g. the recent address-derivation centralization).

[jvsena42]

Heads-up for whoever ports this: the same rescan_with_block_filters also unwrap()s three fallible calls — cfilters.match_any(..) and chain.get_block_height(&block.block_hash()).unwrap().unwrap(). They don't fire under normal operation (a user-requested block is matched back to its request by hashing the received block in check_is_user_block_and_reply, so the delivered block's hash is always one the chain knows, and a bad peer can't trigger it), but they can still panic the spawned rescan task on a filter-store I/O error or a deep reorg — silently aborting the rescan, the same failure class this issue is about.

A follow-up on the fork handles them gracefully (abort+log if filters can't be read; count a height-lookup miss as a failed block and continue): jvsena42#20. Worth folding into the same fix so the retry change and the unwraps are addressed together.