feat(key-wallet): add keep-finalized-transactions Cargo feature#733
Merged
Conversation
Contributor
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR introduces a ChangesKeep-Finalized-Transactions Feature and Implementation
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v0.42-dev #733 +/- ##
=============================================
- Coverage 71.43% 71.26% -0.18%
=============================================
Files 320 320
Lines 68770 68798 +28
=============================================
- Hits 49128 49028 -100
- Misses 19642 19770 +128
|
Member
Author
|
This replaces #709 |
7 tasks
Contributor
|
This PR has merge conflicts with the base branch. Please rebase or merge the base branch into your branch to resolve them. |
github-actions
Bot
added
the
merge-conflict
xdustinface
requested changes
May 6, 2026
Collaborator
xdustinface
left a comment
xdustinface
left a comment
There was a problem hiding this comment.
This will lead to missing out on block confirmations for transactions. We should not see transactions as "finalized" or however you wanna call it until they are confirmed fully confirmed via a chainlock (either at the height they are mined or a later height if the confiming block didnt receive a chainlock) i think.
| // path so e.g. an IS-locked record can transition to ChainLock | ||
| // when the surrounding block confirmation arrives. | ||
| #[cfg(not(feature = "keep-finalized-transactions"))] | ||
| if self.keys.transaction_is_finalized(&txid) { |
Collaborator
There was a problem hiding this comment.
So you will never know when transaction gets confirmed in chain now?
| // the `#[allow(unused_variables)]` keeps clippy happy when the | ||
| // `keep-finalized-transactions` feature is on (no `let _ = ...` | ||
| // cfg shim required). | ||
| #[allow(unused_variables)] |
Collaborator
There was a problem hiding this comment.
Why not use the feature gate here too?
| // the `#[allow(unused_variables)]` keeps clippy happy when the | ||
| // `keep-finalized-transactions` feature is on (no `let _ = ...` | ||
| // cfg shim required). | ||
| #[allow(unused_variables)] |
| { | ||
| return self.finalized_txids.contains(txid); | ||
| } | ||
| #[allow(unreachable_code)] |
Collaborator
There was a problem hiding this comment.
This seems a bit strange.. should use the feature gate properly?
QuantumExplorer
force-pushed
the
claude/keep-finalized-transactions
branch
from
afe76d9 to
a7fca52
Compare
github-actions
Bot
removed
the
merge-conflict
xdustinface
requested changes
May 6, 2026
Collaborator
xdustinface
left a comment
xdustinface
left a comment
There was a problem hiding this comment.
Just a side note, we can still get this PR still in for now i guess but at the moment this will not work really because chainlocks are not propagated/processed in the wallet at this point. There is some work required first to wire them up and some thoughts need to be put in how we deal with historical transactions and if we want to emit events for all of them on after initial sync after the first received chainlock.
Also left few more comments, unused code should be dropped, some renaming we should do i think and the proper feature usage probably makes sense to do too.
| /// Use [`Self::transaction_is_finalized_in_block`] for the stricter | ||
| /// "fully confirmed in a chainlocked block" answer that drives | ||
| /// memory-pruning decisions. | ||
| fn transaction_is_finalized(&self, txid: &Txid) -> bool; |
| /// height / block hash before the chainlock catches up). Only | ||
| /// `InChainLockedBlock` qualifies. This is the trigger for dropping | ||
| /// the full record under the default feature configuration. | ||
| fn transaction_is_finalized_in_block(&self, txid: &Txid) -> bool; |
Collaborator
There was a problem hiding this comment.
Suggested change
| fn transaction_is_finalized_in_block(&self, txid: &Txid) -> bool; | |
| fn transaction_is_finalized(&self, txid: &Txid) -> bool; |
This should probably be just called transaction_is_finalized then now when the original one gets dropped to align with the naming of the feature.
| /// Returns `true` if this account has already processed `txid`, | ||
| /// whether it's still mutable in `transactions` or has been | ||
| /// finalized-and-pruned (under the default feature configuration). | ||
| /// Used as the dedup signal in `confirm_transaction`. |
Collaborator
There was a problem hiding this comment.
Suggested change
| /// Used as the dedup signal in `confirm_transaction`. |
This seems off? How does it dedup there?
| // the `#[allow(unused_variables)]` keeps clippy happy when the | ||
| // `keep-finalized-transactions` feature is on (no `let _ = ...` | ||
| // cfg shim required). | ||
| #[allow(unused_variables)] |
| // the `#[allow(unused_variables)]` keeps clippy happy when the | ||
| // `keep-finalized-transactions` feature is on (no `let _ = ...` | ||
| // cfg shim required). | ||
| #[allow(unused_variables)] |
| { | ||
| return self.finalized_txids.contains(txid); | ||
| } | ||
| #[allow(unreachable_code)] |
| { | ||
| return self.finalized_txids.contains(txid); | ||
| } | ||
| #[allow(unreachable_code)] |
Collaborator
There was a problem hiding this comment.
Proper use of the feature gate?
| /// ChainLock as final. Use [`Self::is_finalized_in_block`] for the | ||
| /// stricter "fully confirmed in a chainlocked block" answer that | ||
| /// drives memory-pruning decisions. | ||
| pub fn is_finalized(&self) -> bool { |
Collaborator
There was a problem hiding this comment.
This is unused, should be dropped.
| /// block confirmation may still arrive and write the height / | ||
| /// block hash before the chainlock catches up). Only | ||
| /// `InChainLockedBlock` qualifies. | ||
| pub fn is_finalized_in_block(&self) -> bool { |
Collaborator
There was a problem hiding this comment.
Suggested change
| pub fn is_finalized_in_block(&self) -> bool { | |
| pub fn is_chain_locked(&self) -> bool { |
We have is_instant_send above so i think we should go with ^ here.
By default, records of chainlocked transactions are now dropped from each managed account's in-memory `transactions` map; only their txids are retained (in a new `finalized_txids` set on `ManagedCoreKeysAccount`) to keep dedup, `has_transaction`, and finality queries working. The opt-in `keep-finalized-transactions` Cargo feature reverts to the old behavior — every processed transaction stays in the map for the wallet's lifetime. The drop is driven off `TransactionContext::is_finalized_in_block` (chainlock only), not `is_finalized` (chainlock or IS-lock), so IS-locked records survive long enough to absorb the surrounding block-confirmation event (xdustinface review on #709). `confirm_transaction` now returns `Option<TransactionRecord>` so callers always observe the record even when it's about to be dropped. The feature is forwarded through `key-wallet-manager` and `key-wallet-ffi`. Three FFI accessors that walk the full `transactions` map (`managed_core_account_get_transaction_count`, `managed_core_account_get_transactions`, `managed_core_account_free_transactions`) are gated to the feature because they would otherwise return a partial history. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Integration tests under `dash-spv-ffi/tests/dashd_sync/` walk the full per-account transaction history (`managed_core_account_get_transactions`, `managed_core_account_get_transaction_count`, `managed_core_account_free_transactions`) to verify end-to-end wallet sync against a regtest dashd. These accessors are gated behind the `keep-finalized-transactions` feature on `key-wallet-ffi`, so under the default feature set they aren't compiled in and the test build fails to resolve the imports. Add `key-wallet-ffi` as a dev-dependency with the feature enabled. Cargo unifies features across the build graph at test time, which makes the gated accessors available in the test binaries without expanding the lib crate's default feature surface. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Address xdustinface review feedback on PR #733: - Drop `TransactionContext::is_finalized()` (the soft IS-or-chainlock check). The wallet now treats only a chainlock as finality. - Rename `TransactionContext::is_finalized_in_block()` to `is_chain_locked()` so the predicate name describes the variant rather than overloading "finalized" — same naming style as the existing `is_instant_send()` helper. - Drop `ManagedAccountTrait::transaction_is_finalized()` (the unused soft-finality variant) and rename `transaction_is_finalized_in_block()` to `transaction_is_finalized()`. Now that there's a single finalization concept, the trait method name aligns with the feature name. - Replace runtime `if cfg!(...) { ... } else { ... }` branches in `ManagedCoreKeysAccount::has_transaction` and `transaction_is_finalized` with two `#[cfg]`-gated function bodies — one per feature configuration. Same for the chainlock-driven drop call in `confirm_transaction` / `record_transaction`: the `let drop_now = …` binding now only exists when the feature is off, removing the `#[allow(unused_variables)]` workaround. - Rewrite the doc on `has_transaction` so it's clear what it actually reports (live record OR finalized-txid marker) and how callers use it (distinguish brand-new sightings from re-processings) instead of the misleading "dedup signal in `confirm_transaction`" wording. Drop logic still triggers on the strict `is_chain_locked()` check — IS-locked-but-not-yet-chainlocked records still survive so the surrounding block-confirmation event can populate height / block hash before the chainlock catches up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
QuantumExplorer
force-pushed
the
claude/keep-finalized-transactions
branch
from
2f0f2e9 to
eb5afa2
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
key-wallet/src/tests/keep_finalized_transactions_tests.rs (1)
1-155: ⚡ Quick winAlign this new test module with the repository’s required test-module layout.
Please move/merge these cases into one of the prescribed
key-wallet/src/testsmodules (e.g., transaction-focused module) instead of introducing a new top-level test filename.As per coding guidelines,
key-wallet/src/tests/**/*.rs: "Organize unit tests by functionality into separate test modules: account_tests.rs, address_pool_tests.rs, transaction_tests.rs, wallet_tests.rs, integration_tests.rs, balance_tests.rs, spent_outpoints_tests.rs, special_transaction_tests.rs, advanced_transaction_tests.rs, managed_account_collection_tests.rs, backup_restore_tests.rs, edge_case_tests.rs, performance_tests.rs".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@key-wallet/src/tests/keep_finalized_transactions_tests.rs` around lines 1 - 155, You created a new top-level test file with several transaction-focused tests (test_chainlocked_record_kept_when_feature_on, test_chainlocked_record_dropped_when_feature_off, test_islocked_record_kept_when_feature_off, test_islocked_then_chainlocked_drops_at_chainlock) which violates the repo test-module layout; move/merge these tests into the existing transaction test module (e.g., key-wallet/src/tests/transaction_tests.rs). To fix: remove this new file and copy each test function (preserving their cfg attributes and tokio signatures) into transaction_tests.rs, add or reconcile required imports (ManagedAccountTrait, TestWalletContext, BlockInfo, TransactionContext, InstantLock where cfg(not(feature = "keep-finalized-transactions"))), and run cargo test to ensure no duplicate symbols or missing imports; adjust any module-level docs to match surrounding tests and keep the tests grouped by functionality in transaction_tests.rs.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@key-wallet/Cargo.toml`:
- Around line 27-28: Update the feature documentation comment that references
the old method name `transaction_is_finalized_in_block` to the current API
method `transaction_is_finalized`; specifically, replace the stale symbol in the
comment so it matches the implemented API name (e.g., update any occurrence of
`transaction_is_finalized_in_block` to `transaction_is_finalized` near the
feature docs mentioning `has_transaction` / `transaction_is_finalized`).
---
Nitpick comments:
In `@key-wallet/src/tests/keep_finalized_transactions_tests.rs`:
- Around line 1-155: You created a new top-level test file with several
transaction-focused tests (test_chainlocked_record_kept_when_feature_on,
test_chainlocked_record_dropped_when_feature_off,
test_islocked_record_kept_when_feature_off,
test_islocked_then_chainlocked_drops_at_chainlock) which violates the repo
test-module layout; move/merge these tests into the existing transaction test
module (e.g., key-wallet/src/tests/transaction_tests.rs). To fix: remove this
new file and copy each test function (preserving their cfg attributes and tokio
signatures) into transaction_tests.rs, add or reconcile required imports
(ManagedAccountTrait, TestWalletContext, BlockInfo, TransactionContext,
InstantLock where cfg(not(feature = "keep-finalized-transactions"))), and run
cargo test to ensure no duplicate symbols or missing imports; adjust any
module-level docs to match surrounding tests and keep the tests grouped by
functionality in transaction_tests.rs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3b9d0bdb-919d-4d45-b9ad-6fd64a818a6a
📒 Files selected for processing (13)
dash-spv-ffi/Cargo.tomlkey-wallet-ffi/Cargo.tomlkey-wallet-ffi/FFI_API.mdkey-wallet-ffi/src/managed_account.rskey-wallet-manager/Cargo.tomlkey-wallet/Cargo.tomlkey-wallet/src/managed_account/managed_account_trait.rskey-wallet/src/managed_account/managed_core_funds_account.rskey-wallet/src/managed_account/managed_core_keys_account.rskey-wallet/src/tests/keep_finalized_transactions_tests.rskey-wallet/src/tests/mod.rskey-wallet/src/transaction_checking/transaction_context.rskey-wallet/src/transaction_checking/wallet_checker.rs
The previous commit renamed the trait method to `transaction_is_finalized` but missed this Cargo.toml feature-doc reference. Caught by CodeRabbit on PR #733. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
xdustinface
approved these changes
May 7, 2026
This was referenced May 7, 2026
QuantumExplorer
added a commit
that referenced
this pull request
May 7, 2026
…#742) * refactor(key-wallet): wire ManagedCoreKeysAccount into the collection Promotes the dead-code `ManagedCoreKeysAccount` introduced in #711 into the active type for accounts that derive special-purpose keys but don't track funds. Cuts ~10 keys-only accounts per wallet from carrying always-empty `balance` / `utxos` / `spent_outpoints` state. Storage split on `ManagedAccountCollection`: - Identity, asset-lock, and provider fields move from `ManagedCoreFundsAccount` → `ManagedCoreKeysAccount`. - Standard, CoinJoin, and DashPay fields stay on `ManagedCoreFundsAccount`. New borrowed enum `ManagedAccountRef<'a> { Funds, Keys }` (and mutable counterpart `ManagedAccountRefMut<'a>`) plus owned `OwnedManagedCoreAccount`. Spanning collection accessors (`get_by_account_type_match`, `all_accounts`, …) return the borrowed enum. The enum delegates the funds-agnostic surface (transactions, monitor revision, address-pool helpers, record/confirm transaction) so most callers don't need to dispatch on the variant; funds- only operations (`as_funds()`, `as_funds_mut()`) require an explicit unwrap. `ManagedCoreKeysAccount` gains the methods needed to be a first-class participant in transaction matching: - `record_transaction` / `confirm_transaction` (no UTXO/balance work) - `check_transaction_for_match`, `check_asset_lock_transaction_for_match`, and the four `check_provider_*_key_in_transaction_for_match` variants - `classify_address` / `check_provider_payout` helpers `wallet/managed_wallet_info` accessors that returned `&mut ManagedCoreFundsAccount` for identity / asset-lock / provider accounts now return `&mut ManagedCoreKeysAccount`. Funds-only surfaces (`account_balances`, `update_balance`, `mark_instant_send_utxos`, matured-coinbase / immature) filter to the funds variant. `ManagedAccountCollection::insert` accepts either variant via `OwnedManagedCoreAccount`; explicit `insert_funds` / `insert_keys` helpers are exposed for callers that statically know the variant. `get`, `get_mut`, `remove`, `contains_key` now scope to the funds-bearing index lookup (Standard BIP44/32 + CoinJoin) — keys accounts use type-keyed accessors. C ABI preserved on the FFI side. `FFIManagedCoreAccount` now wraps an internal `Funds | Keys` enum carrying an `Arc<…>`, with new `as_funds` / `as_keys` / `keys_account` accessors and a `new_keys` constructor. Funds- only entry points (`get_balance`, `get_utxo_count`) gracefully return defaults on the keys variant; trait-shared entry points (`get_network`, `get_account_type`, address-pool getters, transactions) work on both. Variant-aware constructors are wired through `managed_wallet_get_account`, `managed_wallet_get_top_up_account_with_registration_index`, and the per-type collection getters. This is a clean replay of the work from PR #716 on the current architecture (the original branch carried merge noise from unrelated discarded branches and depended on pre-#711 / pre-#733 struct layouts that no longer exist). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(key-wallet-ffi): rustdoc + regenerate FFI_API.md - Drop intra-doc links to private `FFIManagedCoreAccountInner` variants on `keys_account()` so `cargo doc -D warnings` (and the Documentation CI job) passes; the enum is internal and doesn't need to appear in public rustdoc. - Regenerate `key-wallet-ffi/FFI_API.md` to pick up the updated descriptions on `managed_core_account_get_balance` / `_get_utxo_count` (the verify-ffi pre-commit hook). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(key-wallet-ffi): include all account variants in managed_wallet_get_account_count The count was only summing standard / coinjoin / identity_registration / identity_topup buckets — every other variant `managed_wallet_get_account` can return (identity_topup_not_bound, identity_invitation, asset-lock, provider, dashpay, platform-payment) was excluded. Pre-existing miscount, made more visible by the keys-account split now exposing those getters through the variant-aware FFI surface. `provider_operator_keys` (BLS) and `provider_platform_keys` (EdDSA) are feature-gated on the immutable `AccountCollection` and counted only when the corresponding feature is enabled. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): add `all_funding_accounts(_mut)` and drop in-loop `as_funds()` filters Five funds-only callsites in `wallet_info_interface.rs` were iterating `all_accounts()` and filtering each ref via `as_funds()` / `as_funds_mut()` inside the loop body — pure noise, since balance / UTXO state only ever lives on Standard / CoinJoin / DashPay accounts. Add focused accessors on `ManagedAccountCollection`: - `all_funding_accounts(&self) -> Vec<&ManagedCoreFundsAccount>` - `all_funding_accounts_mut(&mut self) -> Vec<&mut ManagedCoreFundsAccount>` Migrate `account_balances`, `utxos`, `update_balance`, `immature_transactions`, and `matured_coinbase_records` to use them. `monitored_addresses`, `transaction_history`, `monitor_revision`, and `mark_instant_send_utxos` keep using `all_accounts(_mut)` — they legitimately span both variants. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): rename insert_{funds,keys} -> insert_{funds,keys}_bearing_account `insert_funds` / `insert_keys` were ambiguous about *what* "funds" or "keys" referred to. The longer names make the variant intent explicit and match the surrounding "funds-bearing" / "keys-only" terminology already used in the doc comments and field comments. The generic `insert(impl Into<OwnedManagedCoreAccount>)` keeps its name — that's the variant-agnostic entry point. No public callers existed outside this file (verified via grep across key-wallet, key-wallet-ffi, key-wallet-manager, dash-spv) so this is a local rename with no downstream impact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): simplify keys-account `record_transaction` to its real semantics The keys-account `record_transaction` was carrying three branches that are statically unreachable on the keys-account data model: - `change_addrs` — for non-Standard `CoreAccountTypeMatch` variants, `involved_change_addresses()` is always `&[]`. Identity / asset-lock / provider accounts own a single address pool with no external/internal split, so the `OutputRole::Change` arm can never match. - `OutputRole::Sent` — gated on `has_inputs = account_match.sent > 0`, but the keys-account `check_transaction_for_match` sets `sent = 0` unconditionally (keys accounts don't track per-account UTXOs, so there's no signal that they contributed inputs). - `direction = Internal | Outgoing` — both gated on `has_inputs`, same dead-branch reason. A keys account always sees direction `Incoming` (or `CoinJoin` for the unlikely-but-possible case where the upstream classifier flagged a CoinJoin tx that touched a keys-account address). Drop the dead branches, rename `receive_addrs` → `owned_addrs` (no receive/change distinction exists for these account types), and document the actual semantics on the method's doc comment. Behavior is preserved — the previous code happened to compute the right answer through dead arms; the new code expresses it directly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): make keys-account `record_transaction` a thin marker Keys-account flows (identity registration, asset lock, provider-key registration / update) are typically funded from a Standard or CoinJoin account in the same wallet. The funding account's `record_transaction` already populates `input_details` (from its UTXO set) and `output_details` (classified receive / change / sent), so the keys-account record reproducing them would double-count and risk drifting out of sync if the classification logic changes. Treat the keys-account record as the thin marker it really is: "this tx involved this keys account" plus `net_amount`, and nothing more. - `direction = TransactionDirection::Internal` — from the wallet's perspective, the tx moves funds from one of its accounts to another. - `input_details = Vec::new()` — already correct (keys accounts don't track per-account UTXOs). - `output_details = Vec::new()` — the funding account's record carries the per-output classification. Drop the now-unused `OutputDetail` / `OutputRole` / `Address` imports and gate the `HashSet` import behind the same feature flag as `finalized_txids`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(key-wallet): cover special-tx → keys-account matching paths end-to-end For each special-transaction type that drives one of the new keys-account `check_*_for_match` methods on `ManagedCoreKeysAccount`, construct a transaction and assert `ManagedWalletInfo::check_core_transaction` flags the right `AccountTypeToCheck`. 13 tests in `tests/special_transaction_matching_tests.rs`: - AssetLockPayloadType → 6 tests covering each of the keys-account variants (Identity{Registration, TopUp, TopUpNotBound, Invitation}, AssetLock{Address, Shielded}TopUp). - ProviderRegistrationPayloadType → 4 tests, one per provider-key match field (owner_key_hash, voting_key_hash, operator_public_key (BLS), platform_node_id (EdDSA)). The BLS / EdDSA tests are feature-gated the same way the matching impls are. - ProviderUpdateRegistrarPayloadType → 2 tests (voting + operator key changes). - 1 test pinning the keys-account `TransactionRecord` shape: direction Internal, empty input/output details (the post-PR thin-marker contract). Skipped on purpose: - AssetUnlock / Coinbase — match Standard, not the keys-only variants. - QuorumCommitment — no key/address fields the wallet matches against. - ProviderUpdateRevocation — payload has no key-hash / pubkey field for matching. Also fixes a real PR-introduced bug surfaced by writing the IdentityTopUp test: `add_managed_account` / `add_managed_account_from_xpub` always constructed `ManagedCoreFundsAccount` regardless of the account type, then relied on `insert()` accepting it — which now correctly errors for keys-only types after the variant split. The fix dispatches via a small `owned_from_account` helper that picks the right variant, and the BLS / EdDSA paths (always ProviderOperatorKeys / ProviderPlatformKeys, both keys-only) drop their `ManagedCoreFundsAccount::from_*_account` calls in favor of `ManagedCoreKeysAccount::from_*_account`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): keep `from_account_collection` field-direct insertions The earlier refactor in this PR routed every `from_account_collection` case through `managed_collection.insert(managed_account)` where `managed_account` was an `OwnedManagedCoreAccount`. That swapped 14 trivial field-typed inserts (e.g. `standard_bip44_accounts.insert(*index, managed)`) for 14 generic-insert calls — each having to carry a `.expect()` for an invariant the old code never had to articulate. Restore the field-direct shape: - `create_managed_account_from_account_type` (returned the owned enum) is renamed to `build_managed_account_type` and returns the inner [`ManagedAccountType`]. That's the actual shared work — building the address pools. - Per-variant thin wrappers wrap it as the right concrete type: - `create_managed_funds_account_from_account` → `ManagedCoreFundsAccount` - `create_managed_keys_account_from_account` → `ManagedCoreKeysAccount` - `create_managed_keys_account_from_bls_account` (ProviderOperatorKeys, always keys) - `create_managed_keys_account_from_eddsa_account` (ProviderPlatformKeys, always keys) - `from_account_collection` does the field-direct insert each variant expects — same shape as the original code. - `is_funds_bearing_account_type` was only used by the old funnel and is now removed. The variant-aware `insert(impl Into<OwnedManagedCoreAccount>)` and the explicit `insert_funds_bearing_account` / `insert_keys_bearing_account` remain as the public entry points for callers that genuinely need the runtime-dispatched insert (e.g. `add_managed_account`). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Opt-in
keep-finalized-transactionsCargo feature that drops the fullTransactionRecordfor transactions that have reached a finalized state (InstantSend lock or ChainLock — both signal the transaction can never change state again) and keeps only the txid in a per-accountfinalized_txids: HashSet<Txid>. Bounds memory growth in long-lived wallets without losing dedup.Public API
Added to
ManagedAccountTrait(always available, both feature configs):fn has_transaction(&self, txid: &Txid) -> bool— true if the tx is either still intransactions(active) or has been dropped intofinalized_txids(finalized). Used as the dedup signal inconfirm_transaction.fn transaction_is_finalized(&self, txid: &Txid) -> bool— true only when the txid is infinalized_txids. Alwaysfalsewith the feature off (no finalization tracking).ManagedAccountTransactionsTrait::transactions()/transactions_mut()remain as before. With the feature on the map only contains non-finalized records — finalized ones are gone, so iterating the map will not see them.confirm_transactionnow returnsOption<TransactionRecord>instead ofbool. The record is cloned BEFORE any finalization so callers can still emit events even when the record has just been dropped from the map.TransactionContext::is_finalized()returns true forInstantSend(_)orInChainLockedBlock(_).Behavior
record_transaction(.., context, ..)— ifcontext.is_finalized(), the record is inserted then immediately dropped, with the txid added tofinalized_txids. Returns the cloned record.confirm_transaction(.., context, ..)— short-circuits when the txid is already finalized (no record left to update). Otherwise updates the existing context, captures the record, then finalizes if the new context is finalized.mark_instant_send_utxos(wallet-level) — also callsfinalize_transactionso IS-lock arrivals through that path drop the record consistently.Defaults
key-walletenables it, socargo test -p key-walletruns the feature-on path. Existing tests that explicitly asserted record content after IS-lock/chainlock are gated to#[cfg(not(feature = \"keep-finalized-transactions\"))].key-wallet-managerandkey-wallet-ffiexpose akeep-finalized-transactionsfeature that forwards tokey-wallet.Test plan
cargo build --workspace(default — feature off) buildscargo build --workspace --features key-wallet-ffi/keep-finalized-transactionsbuildscargo test -p key-wallet --lib --test-threads=1— 463 passed (feature on via dev-dep, includes 4 new feature tests)cargo test -p key-wallet --no-default-features --features test-utils,serde,bincode,getrandom,bls,eddsa,bip38 --lib --test-threads=1— 463 passed (feature off; gates the new tests, exercises legacy ones)cargo test -p key-wallet-manager --all-features— 31/7/5/2/0 ✅cargo clippy --workspace --testscleancargo fmt --checkcleanNew focused tests in
key-wallet/src/tests/keep_finalized_transactions_tests.rs:instantsend_drops_record_and_records_finalization— mempool → IS-lock drops the record;has_transactionstill true;transaction_is_finalizedtrue.chainlock_drops_record_and_records_finalization— InBlock alone is NOT finalization; chainlock drops the record.first_sighting_already_finalized_drops_record_immediately— record + finalize in a single call when the first event is IS-lock.replays_after_finalize_dont_double_count_or_resurrect_record— stale block events for already-finalized txs don't resurrect the record or change UTXOs/balance.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
keep-finalized-transactionsfeature flag to enable full transaction history retention in wallets (by default, finalized transactions are pruned).Documentation
Tests