Return wallet events when applying updates#310
Return wallet events when applying updates#310notmandatory merged 4 commits intobitcoindevkit:release/2.2from
Conversation
Pull Request Test Coverage Report for Build 17985287671Details
💛 - Coveralls |
5e28992 to
1ce9292
Compare
764b4be to
0c3361c
Compare
|
After I get a 👍 from @tnull on the I'd also like to get feedback from any other wallet devs and the FFI team on how this could help with building more responsive wallet apps. A few TODOs I have left are:
I'm not planning to add an events version of After this PR is done I'll create a breaking PRs for the 3.0 milestone that deprecates the new function and modifies the function signature of |
0c3361c to
14f847a
Compare
tnull
left a comment
There was a problem hiding this comment.
Generally looks good! I left some comments. Mostly I still think that some of these variants are too verbose and/or could be combined, potentially by tracking some optional fields. But no strong opinion/no blocker from my side.
wallet/src/wallet/event.rs
Outdated
| /// A confirmed transaction is now confirmed in a new block. | ||
| /// | ||
| /// This can happen after a chain reorg. | ||
| TxConfirmedNewBlock { |
There was a problem hiding this comment.
Maybe TxConfirmationStatusChanged or similar?
There was a problem hiding this comment.
I combined with TxConfirmed and added old_block_time to indicate the Tx changed blocks instead of using a new event.
I looked/experimented with BDK, particularly the `bdk_chain`, and I think [this method](https://docs.rs/bdk_chain/latest/bdk_chain/struct.CheckPoint.html#method.insert) is sufficient to remove the store entirely instead of deprecating it. Since every block header is now emitted, the `bdk_kyoto` integration can make use of this to avoid starting on an orphan block. Reorganizations don't need to be explicitly emitted. Rather, the node can just emit whatever chain it is on and `CheckPoint::insert` will reconsile the changes. It looks like there will also be nice [user facing events](bitcoindevkit/bdk_wallet#310), so explicitly informing about a re-org might even be returned in the wallet update. This Kyoto now acts as a decision-maker for the the chain of most work, but there is now a single source-of-truth for the history of headers.
I looked/experimented with BDK, particularly the `bdk_chain`, and I think [this method](https://docs.rs/bdk_chain/latest/bdk_chain/struct.CheckPoint.html#method.insert) is sufficient to remove the store entirely instead of deprecating it. Since every block header is now emitted, the `bdk_kyoto` integration can make use of this to avoid starting on an orphan block. Reorganizations don't need to be explicitly emitted. Rather, the node can just emit whatever chain it is on and `CheckPoint::insert` will reconsile the changes. It looks like there will also be nice [user facing events](bitcoindevkit/bdk_wallet#310), so explicitly informing about a re-org might even be returned in the wallet update. This Kyoto now acts as a decision-maker for the the chain of most work, but there is now a single source-of-truth for the history of headers.
14f847a to
9b1af09
Compare
|
@tnull thanks for the suggestions, I've updated the events to combine |
9b1af09 to
57efed0
Compare
57efed0 to
0c5a087
Compare
|
Thanks for the feedback @oleonardolima, fixed. |
72e13bc to
8112805
Compare
There was a problem hiding this comment.
Tested ACK 0c5f4a4.
I think I'll need to use it and see it in production before I get the feel for whether this is all I want/need and in the format I want it, so it's great that you can release this in the 2.2! We should be able to provide polish to the feature if ever it's needed for the 3.0 release.
Thanks for writing the ADR. Very helpful, now and in the future.
| /// Transaction id. | ||
| txid: Txid, | ||
| /// Transaction. | ||
| tx: Arc<Transaction>, |
There was a problem hiding this comment.
Wondering if we need the whole transaction here. Feels like the txid is enough information for the "messaging" purpose of this WalletEvent type, but maybe you had something in mind for it?
There was a problem hiding this comment.
This is just a pointer to a Transaction that already exists in the Wallet's local chain so doesn't cost much to include it and could be useful for a caller who wants to look through it. But I agree it's not strictly needed since the user has the Txid and could call Wallet::get_tx() to get the full WalletTx which includes the Arc<Transaction> .
I suspect even for the bdk-ffi bindings this field would still be an Arc<Transaction> so shouldn't cost much there to included it either. But I haven't tried to implement the bindings for this yet.
@tnull do you think your project will use this Arc to the full Transaction ?
| /// Transaction id. | ||
| txid: Txid, | ||
| /// Transaction. | ||
| tx: Arc<Transaction>, |
There was a problem hiding this comment.
Same as above. Wondering about the reason for the full tx to be returned here.
5dfb09e to
0a176ce
Compare
|
|
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.
0a176ce to
c6fb9b3
Compare
I looked/experimented with BDK, particularly the `bdk_chain`, and I think [this method](https://docs.rs/bdk_chain/latest/bdk_chain/struct.CheckPoint.html#method.insert) is sufficient to remove the store entirely instead of deprecating it. Since every block header is now emitted, the `bdk_kyoto` integration can make use of this to avoid starting on an orphan block. Reorganizations don't need to be explicitly emitted. Rather, the node can just emit whatever chain it is on and `CheckPoint::insert` will reconsile the changes. It looks like there will also be nice [user facing events](bitcoindevkit/bdk_wallet#310), so explicitly informing about a re-org might even be returned in the wallet update. This Kyoto now acts as a decision-maker for the the chain of most work, but there is now a single source-of-truth for the history of headers.
I looked/experimented with BDK, particularly the `bdk_chain`, and I think [this method](https://docs.rs/bdk_chain/latest/bdk_chain/struct.CheckPoint.html#method.insert) is sufficient to remove the store entirely instead of deprecating it. Since every block header is now emitted, the `bdk_kyoto` integration can make use of this to avoid starting on an orphan block. Reorganizations don't need to be explicitly emitted. Rather, the node can just emit whatever chain it is on and `CheckPoint::insert` will reconsile the changes. It looks like there will also be nice [user facing events](bitcoindevkit/bdk_wallet#310), so explicitly informing about a re-org might even be returned in the wallet update. This Kyoto now acts as a decision-maker for the the chain of most work, but there is now a single source-of-truth for the history of headers.
…0 milestone) fcdc006 docs: Add ADR `0003_events.md` (Steve Myers) acbfb67 test: Add `tests/wallet_events.rs` (Steve Myers) ec3d1e0 feat(wallet): Add `Wallet::apply_update_events` (Steve Myers) 6467969 feat(wallet): Introduce `WalletEvent` (Steve Myers) 132d4b6 docs: Fix typo (Steve Myers) Pull request description: ### Description Cherry-pick of commits from #310 and #336. ### Notes to the reviewers See #319 (comment) for proposed follow-up work. ### Changelog notice No changes from `release/2.x` branch. BREAKING: - `wallet::event` module is made private. `WalletEvent` can now be imported from the root level. ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `just p` before pushing #### New Features: * [x] I've added tests for the new feature * [x] I've added docs for the new feature * [x] This pull request breaks the existing API Top commit has no ACKs. Tree-SHA512: bbe0c48175543413a75b4dc7b5e3a59dd0186aadab08dc8af8f14dcb4a90444bcfece1c3f6fc8474949b98a0e925ad91ef30aae53fefefdcbff55cbb09d64ea1
Description
Adds
WalletEventenum of user facing events that are generated when a sync update is applied to a wallet using thenew
Wallet::apply_update_eventsfunction.fixes #6
Notes to the reviewers
I also modified wallet test_utils to add a
new_wallet_and_funding_updatefunction that returns a new wallet with an update that funds it. I used this new function in the originalnew_funded_walletso there's no duplication.Changelog notice
Checklists
All Submissions:
just pbefore pushingNew Features: