DanSandClaude Opus 5.5
c233d4d503
At the end of a sync the wallet fetches the full transaction of each new wallet tx, together with every other transaction in the blocks that contain them, as decoys. Every txid got its own pool job that built a fresh Tokio runtime (one thread per CPU), a new rustls config and a new TCP + TLS + HTTP/2 connection for a single GetTransaction call, so a restore or rescan opened one connection per fetched transaction. The first error returned from the sync while the remaining jobs kept fetching and scanning in the background, and a stalled connection, an unparsable transaction or a panicking scan could hang the sync forever with its lock held. fulltx_fetch.rs now works through the same (txid, height)-sorted, de-duplicated list on the sync's runtime, with as many workers as the sync pool has threads (2-8, the same fan-out as before), over one gRPC channel that is dialed lazily and re-dialed on retry. Parsing and scanning stay on the sync pool, and the call returns once the whole batch has finished. Behaviour changes: - a failure on a decoy no longer fails the sync; it fails only when one of the wallet's own txs could not be fetched and scanned; - new error texts "Error reading transaction: ...", "full tx scan job panicked" and "fetched only X of Y wallet txs", all after the existing "Error fetching all txns for memos: " prefix; - each tx gets up to 3 fetch attempts with a 120 s timeout each, where the old code could wait forever; a request that legitimately takes longer now fails; - nothing keeps running in the background after the sync returns; - all GetTransaction calls share one TLS/HTTP-2 connection (up to one dial per worker at the start, plus a re-dial per retry); the request list and its order are unchanged; - if the network silently drops packets mid-batch, every attempt waits out its timeout until 16 consecutive failed txs stop the batch: up to about 12 minutes with 8 workers (48 minutes with 2) with the sync lock held, where the old code gave up at its first failed connection. Which txs are requested, in what order, how often they are retried and when the batch stops do not depend on which txs are the wallet's own; only the final result does. A server that keeps failing one tx can see that result through the sync's retry, but it could already tell, because an own tx that failed is requested again on the next sync without its decoys; nothing new leaks. tests/fulltx_fetch.rs drives the engine with a fake fetcher: the old request list, each item fetched and scanned once, bounded concurrency, a request sequence independent of ownership, retries, timeouts, the breaker, panicking and unparsable scans, and a saved wallet byte-identical to the old serial fill. The gRPC fetcher itself is not covered by these tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
31 lines
895 B
Rust
31 lines
895 B
Rust
// Copyright The Hush Developers 2019-2022
|
|
// Released under the GPLv3
|
|
#[macro_use]
|
|
extern crate rust_embed;
|
|
|
|
pub mod lightclient;
|
|
pub mod grpcconnector;
|
|
pub mod fulltx_fetch;
|
|
pub mod lightwallet;
|
|
pub mod commands;
|
|
|
|
#[cfg(feature = "embed_params")]
|
|
#[derive(RustEmbed)]
|
|
#[folder = "zcash-params/"]
|
|
pub struct SaplingParams;
|
|
|
|
#[derive(RustEmbed)]
|
|
#[folder = "res/"]
|
|
pub struct PubCertificate;
|
|
|
|
|
|
// Anchor depth back from the tip for shielded spends. MUST be > 0: with 0 the wallet anchors to
|
|
// the absolute chain tip, which races the node committing that anchor and intermittently triggers
|
|
// "bad-txns-shielded-requirements-not-met" (missing sapling anchor) on broadcast. 4 matches upstream
|
|
// zecwallet-lite and uses a confirmed, reorg-stable anchor.
|
|
pub const ANCHOR_OFFSET: u32 = 4;
|
|
|
|
pub mod grpc_client {
|
|
tonic::include_proto!("cash.z.wallet.sdk.rpc");
|
|
}
|