feat: offline mode#2371
Conversation
| use zingolib::lightclient::LightClient; | ||
| use zingolib::wallet::{PerformanceLevel, SyncConfig, TransparentAddressDiscovery, WalletSettings}; | ||
|
|
||
| /// A 24-word BIP-39 mnemonic used only for this demonstration. |
There was a problem hiding this comment.
This mnemonic is used elsewhere.. the comment seems to imply that it's used here EXCLUSIVELY.
My concern is that we may have turned a compile-time gap into a runtime panic: if any zcash_client_backend path we now reach calls one of these accessors, it aborts. We MUST guarantee at compile time that the accessor calls can't cause a panic (for example... even if there's a malicious ZCB). Can we write an adversarial test that causes a panic?
Both call write_to_path, which always writes to the same wallet_path.with_extension("…tmp"). The wallet().write() lock serializes serialization but not the subsequent file write, so a consumer calling flush() while the background save_task is running can have two writers truncate/interleave the same .tmp before the rename. Please add an adversarial test that causes interleaving and is fixed by uniquifying the temp filename.
The offline branch returns format!("{e:?}"), which collapses to "Offline" and loses the helpful Display message ("Offline: no indexer configured. Call set_indexer_uri() to connect."). Make do_info return a structured type, so we can leverage Display properly.
The current tests cover the offline error paths thoroughly but not the transition that's the whole point of the feature: construct offline, call set_indexer_uri(), then confirm network ops no longer return Offline. Even a no-network assertion that indexer_uri().is_some() after set_indexer_uri would lock in the happy path. |
There was a problem hiding this comment.
Add tests proving that neither pepper-sync, nor any other network-requiring functionality, CAN be exercised in offline-mode.
These guarantees MUST be fully auditable at compile-time.
I.E. All paths that exercise network-dependent logic must be conditionally INaccessible in offline-mode, and that condition MUST be enforced at a Single Point.
|
Consider an offline-only feature-gate that compiles only offline functionality. |
|
Another TODO: feature-gate online capabilities AND make it the default! |
The wallet_from_file example calls tracing_subscriber::fmt() but zingolib only declared `tracing`, so `cargo check --examples` failed. Wire the existing workspace tracing-subscriber dependency into zingolib's dev-dependencies, matching how the example already pulls in tempfile. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
No description provided.