Return wallet events when applying updates (3.0 milestone) #319
Conversation
WalletEvent is a enum of user facing events that are generated when a sync update is applied to a wallet using the Wallet::apply_update_events function.
There was a problem hiding this comment.
Hey @notmandatory thanks for your work on this! I left some comments related to code quality. As always, nits are non-blocking.
| }; | ||
|
|
||
| // re-exports | ||
| use crate::event::{wallet_events, WalletEvent}; |
There was a problem hiding this comment.
This would be a good place to re-export the WalletEvent type. That would also help keep the use statements organized.
| .collect::<BTreeMap<Txid, (Arc<Transaction>, ChainPosition<ConfirmationBlockTime>)>>(); | ||
|
|
||
| // apply update | ||
| self.apply_update(update)?; |
There was a problem hiding this comment.
Any reason not to apply the update and use the resulting changeset to produce a summary of what changed in the Wallet?
There was a problem hiding this comment.
The resulting Wallet::ChangeSet only contains the new blocks, tx, and anchors found after applying the sync update but don't show how this new data changes the canonical status of existing tx.
| }, | ||
| } | ||
|
|
||
| pub(crate) fn wallet_events( |
There was a problem hiding this comment.
📌 A code comment somewhere would help to explain what this function is doing.
| if chain_tip1 != chain_tip2 { | ||
| events.push(WalletEvent::ChainTipChanged { | ||
| old_tip: chain_tip1, | ||
| new_tip: chain_tip2, | ||
| }); | ||
| } |
There was a problem hiding this comment.
I think it would be helpful to know which blocks were connected and/or disconnected.
There was a problem hiding this comment.
Do you mean a list of connected/disconnected block ids? I didn't add any other info here because @tnull didn't need it for LDK's use case. Do you have some use or user in mind for this extra info?
| }); | ||
| } | ||
|
|
||
| wallet_txs2.iter().for_each(|(txid2, (tx2, cp2))| { |
There was a problem hiding this comment.
nit: Please use a for loop for this.
There was a problem hiding this comment.
I don't mind using a for loop, but just curious what the benefit is, is it just easier to read?
| } | ||
|
|
||
| wallet_txs2.iter().for_each(|(txid2, (tx2, cp2))| { | ||
| if let Some((tx1, cp1)) = wallet_txs1.get(txid2) { |
There was a problem hiding this comment.
pos1 or chain_position1. "cp" usually signifies something else.
| use bdk_chain::{BlockId, CheckPoint, ConfirmationBlockTime}; | ||
| use bdk_wallet::event::WalletEvent; | ||
| use bdk_wallet::test_utils::{get_test_wpkh_and_change_desc, new_wallet_and_funding_update}; | ||
| use bdk_wallet::{SignOptions, Update}; |
There was a problem hiding this comment.
This will be more future proof if you can do it using the unsigned txs.
|
|
||
| wallet_txs2.iter().for_each(|(txid2, (tx2, cp2))| { | ||
| if let Some((tx1, cp1)) = wallet_txs1.get(txid2) { | ||
| assert_eq!(tx1.compute_txid(), *txid2); |
There was a problem hiding this comment.
Maybe just a debug_assert here.
Pull Request Test Coverage Report for Build 18025823526Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
Description
Cherry-pick of commits from #310.
DRAFT and may modify based on feed back from users with 2.2.
Notes to the reviewers
Changelog notice
Checklists
All Submissions:
just pbefore pushingNew Features:
Bugfixes: