Description
loaddescriptor and rescanblockchain launch the scan with tokio::task::spawn(Self::rescan_with_block_filters(..)) (crates/floresta-node/src/json_rpc/server.rs, ~L123/L168) and return immediately, with no record that a rescan is running. Two consequences:
- No observability.
getblockchaininfo exposes filter download height but nothing about the wallet scan, so a client can't distinguish "filters downloaded" from "wallet fully scanned." Filter download finishing is reported as fully synced while the rescan is still processing blocks.
- No dedup. A second
rescanblockchain (e.g. a user re-tapping a Rescan button) spawns another overlapping task that re-fetches the same blocks, wasting the scarce block-download budget.
Impact
In the Android port the "fully synced" state appears before the wallet scan completes, and re-triggering rescans compounds the dropped-block problem in the related issue (see jvsena42/mandacaru#81).
Suggested fix
Track a rescan-in-progress flag (+ processed/total matched-block counters) on the RPC state, surface it via getblockchaininfo, and have rescanblockchain return a "busy" error instead of spawning a duplicate while one is running. Reference implementation: jvsena42/Floresta-mandacaru#18.
Description
loaddescriptorandrescanblockchainlaunch the scan withtokio::task::spawn(Self::rescan_with_block_filters(..))(crates/floresta-node/src/json_rpc/server.rs, ~L123/L168) and return immediately, with no record that a rescan is running. Two consequences:getblockchaininfoexposes filter download height but nothing about the wallet scan, so a client can't distinguish "filters downloaded" from "wallet fully scanned." Filter download finishing is reported as fully synced while the rescan is still processing blocks.rescanblockchain(e.g. a user re-tapping a Rescan button) spawns another overlapping task that re-fetches the same blocks, wasting the scarce block-download budget.Impact
In the Android port the "fully synced" state appears before the wallet scan completes, and re-triggering rescans compounds the dropped-block problem in the related issue (see jvsena42/mandacaru#81).
Suggested fix
Track a rescan-in-progress flag (+ processed/total matched-block counters) on the RPC state, surface it via
getblockchaininfo, and haverescanblockchainreturn a "busy" error instead of spawning a duplicate while one is running. Reference implementation: jvsena42/Floresta-mandacaru#18.