Skip to content

Conversation

@tnull
Copy link
Contributor

@tnull tnull commented Oct 29, 2025

Description

Previously, we added a new Wallet::apply_update_events method that returned WalletEvents. Unfortunately, no corresponding APIs were added for the apply_block counterparts. Here we fix this omission.

Notes to the reviewers

I opened this towards the release-2.2 branch, but it would probably need another release branch. Or let me know if you prefer to open it against master (which seems to be lacking apply_update_events currently though).

I also added no test coverage given that none seems to exist for Wallet::apply_block in the first place. Let me know if I should add something here.

Checklists

All Submissions:

New Features:

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

cc @notmandatory

@coveralls
Copy link

coveralls commented Oct 29, 2025

Pull Request Test Coverage Report for Build 18988009424

Details

  • 34 of 69 (49.28%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.03%) to 85.079%

Changes Missing Coverage Covered Lines Changed/Added Lines %
wallet/src/wallet/mod.rs 34 69 49.28%
Totals Coverage Status
Change from base Build 18951786142: 0.03%
Covered Lines: 7059
Relevant Lines: 8297

💛 - Coveralls

@ValuedMammal ValuedMammal moved this to In Progress in BDK Wallet Oct 29, 2025
@ValuedMammal ValuedMammal added this to the Wallet 3.0.0 milestone Oct 29, 2025
@ValuedMammal ValuedMammal added the new feature New feature or request label Oct 29, 2025
block: &Block,
height: u32,
) -> Result<Vec<WalletEvent>, CannotConnectError> {
let connected_to = match height.checked_sub(1) {

Choose a reason for hiding this comment

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

Thanks for working on this. I noticed apply_block_events seems to duplicate logic from apply_block. Could we move the event handling from apply_block_connected_to_events into apply_block_events, then have it call apply_block instead of apply_block_connected_to? Would be more consistent with how apply_update_event works and avoid the duplication.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, I intentionally added variants for apply_block as well as for apply_block_connected_to as we may also want to use apply_block_connected_to_events at some point.

Copy link
Collaborator

Choose a reason for hiding this comment

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

You could have apply_block call the new apply_block_events and map the return value to ().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You could have apply_block call the new apply_block_events and map the return value to ().

Hmm, but that would run the (possibly costly) delta calculation for everybody, even if they wouldn't make use of the events. I believe this is why @notmandatory added separate _event variants of the methods in the first place.

Copy link
Member

@notmandatory notmandatory Oct 30, 2025

Choose a reason for hiding this comment

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

In #319 (in v3.0) my plan is to always return events. But for this PR I agree it's best keep the two paths separate so events are only calculated on the _events functions.

@notmandatory
Copy link
Member

PR needs a rebase on the release/2.2 branch to fix the CI issue, see #338.

Previously, we added a new `Wallet::apply_update_events` method that
returned `WalletEvent`s. Unfortunately, no corresponding APIs were added
for the `apply_block` counterparts. Here we fix this omission.
@tnull tnull force-pushed the 2025-10-add-apply-block-events branch from 3039c1b to df444d0 Compare October 30, 2025 09:37
@tnull
Copy link
Contributor Author

tnull commented Oct 30, 2025

PR needs a rebase on the release/2.2 branch to fix the CI issue, see #338.

Rebased on release/2.2, but still wondering if we'd need a release/2.3 branch for this, given it extends API?

@ValuedMammal ValuedMammal changed the base branch from release/2.2 to release/2.3 October 30, 2025 18:52
@ValuedMammal
Copy link
Collaborator

ACK I changed the PR to target release/2.3. I agree having a unit test would be nice. I assume we'll need a similar update to #319 .

Copy link
Member

@notmandatory notmandatory left a comment

Choose a reason for hiding this comment

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

Thanks for doing this. Other than my suggested change to apply_wallet_events() it looks good to me.

I would like to see some tests. If you don't have time to do them I'm happy to push a commit with similar testing as I did for apply_update_events().

@notmandatory
Copy link
Member

notmandatory commented Oct 30, 2025

For the branching question. I'd prefer to have a release/2.x branch that contains a tag for each published release. I don't think we'll need branches to do bug fixes separately for 2.1,2.2 etc.

@tnull
Copy link
Contributor Author

tnull commented Oct 31, 2025

I would like to see some tests. If you don't have time to do them I'm happy to push a commit with similar testing as I did for apply_update_events().

Yes, if you don't mind feel free to push a test case. I'm generally happy to do it, but given it will be the first one for apply_block API in general, you will have much more context to preset some test approach/design.

Also did minor cleanup of apply_update_events tests.
@notmandatory
Copy link
Member

notmandatory commented Nov 1, 2025

I added a few tests for apply_block_events based on the relevant (non-mempool related) tests I made for apply_update_events. I think these are the only ones needed for applying on-chain blocks, but feel free to modify these or add more.

@ValuedMammal ValuedMammal changed the base branch from release/2.3 to release/2.x November 2, 2025 00:10
@ValuedMammal
Copy link
Collaborator

For the branching question. I'd prefer to have a release/2.x branch that contains a tag for each published release. I don't think we'll need branches to do bug fixes separately for 2.1,2.2 etc.

That's a good suggestion.

@ValuedMammal ValuedMammal moved this from In Progress to Needs Review in BDK Wallet Nov 4, 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.

ACK e9a3034

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

Labels

new feature New feature or request

Projects

Status: Needs Review

Development

Successfully merging this pull request may close these issues.

5 participants