Skip to content

Conversation

@notmandatory
Copy link
Member

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:

New Features:

  • I've added tests for the new feature
  • I've added docs for the new feature

Bugfixes:

  • This pull request breaks the existing API
  • I've added tests to reproduce the issue which are now passing
  • I'm linking the issue being fixed by this PR

@notmandatory notmandatory self-assigned this Sep 26, 2025
@notmandatory notmandatory added this to the Wallet 3.0.0 milestone Sep 26, 2025
@notmandatory notmandatory moved this to In Progress in BDK Wallet Sep 26, 2025
@notmandatory notmandatory moved this from In Progress to Todo in BDK Wallet Sep 26, 2025
Copy link
Collaborator

@ValuedMammal ValuedMammal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @notmandatory thanks for your work on this! I left some comments related to code quality. As always, nits are non-blocking.

.collect::<BTreeMap<Txid, (Arc<Transaction>, ChainPosition<ConfirmationBlockTime>)>>();

// apply update
self.apply_update(update)?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to apply the update and use the resulting changeset to produce a summary of what changed in the Wallet?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this as an "Option 4" to the ADR 0003.

Comment on lines +94 to +102
if chain_tip1 != chain_tip2 {
events.push(WalletEvent::ChainTipChanged {
old_tip: chain_tip1,
new_tip: chain_tip2,
});
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be helpful to know which blocks were connected and/or disconnected.

Copy link
Member Author

@notmandatory notmandatory Oct 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I mean the block IDs. It's just a more complete way of describing how the chain tip changed.

@coveralls
Copy link

coveralls commented Oct 5, 2025

Pull Request Test Coverage Report for Build 18893642494

Details

  • 158 of 161 (98.14%) changed or added relevant lines in 3 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.2%) to 85.16%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/wallet/event.rs 79 82 96.34%
Totals Coverage Status
Change from base Build 18891447990: 0.2%
Covered Lines: 7110
Relevant Lines: 8349

💛 - Coveralls

@ValuedMammal ValuedMammal moved this from Todo to In Progress in BDK Wallet Oct 7, 2025
@notmandatory notmandatory force-pushed the feat/changeset_events_300 branch from 826bb68 to 21eaa1f Compare October 28, 2025 20:59
# Conflicts:
#	src/wallet/event.rs
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.
@notmandatory notmandatory force-pushed the feat/changeset_events_300 branch from 21eaa1f to 488b373 Compare October 29, 2025 00:11
@notmandatory
Copy link
Member Author

Addressed initial comments from @ValuedMammal and rebased on master branch.

Next steps:

  • remove Wallet::apply_update_events and change Wallet::apply_update to return events instead
  • investigate returning events from Wallet::apply_block
  • add examples for getting affected UTXOs/addresses from tx related WalletEvents

per suggestions from ValuedMammal:
1. re-export WalletEvent type
2. add comments to wallet_events function
3. rename ambiguous variable names in wallet_events from cp to pos
4. remove signing from wallet_event tests
5. change wallet_events function assert_eq to debug_asset_eq
6. update ADR 0003 decision outcome and add option 4 re: creating events only from Update
@notmandatory
Copy link
Member Author

I will cherry-pick and incorporate commits from #336 for apply_block_events and apply_block_connected_to_events when it's merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

3 participants