bitcoindevkit / bdk / 17567940925

79%

Build Type

push

github

Committed by evanlinjin

Commit Message

Merge bitcoindevkit/bdk#2000: `FilterIter` API redesign

6aa81fe2f test(bitcoind): Test 6-block reorg to `filter_iter_detects_reorgs` test (志宇)
4b295eec7 docs(bip158): Update `FilterIter` documentation (valued mammal)
2181c4bab feat(rpc)!: `FilterIter` API redesign (valued mammal)

Pull request description:

  Previously `FilterIter` did not detect or handle reorgs between `next` calls, meaning that if a reorg occurred, we might process blocks from a stale fork potentially resulting in an invalid wallet state. This PR aims to fix that by adding logic to explicitly check for and respond to a reorg on every call to `next`.

  ### Notes to the reviewers

  The old implementation required storing block IDs of scanned blocks before creating a checkpoint update, but because the interface was split across different methods, it introduced a timing risk between method calls which, when we consider the possibility of reorgs, made the implementation somewhat brittle.

  To address this, we make sure that 1) Finding the start block and 2) Updating the internal checkpoint are directly tied to the logic of `next`. Since the checkpoint in practice is derived from a clone of the local chain, this ensures that the checkpoint returned by `next` can always find a connection point with the receiver. Additionally we now emit a checkpoint at every height to ensure that any "must-include" heights are not missing.

  For example usage see `examples/filter_iter.rs`

  fixes #1848

  ### Changelog notice

      Fixed
      - `FilterIter` now handles reorgs to ensure consistency of the header chain.

      Changed
      - `Event` is now a struct instead of enum

      Added
      - `FilterIter::new` constructor that takes as input a reference to the RPC client, checkpoint, and a list of SPKs.
      - `Error::ReorgDepthExceeded` variant
      - `Error::TryFromInt` variant

      Removed
... (continued)

Run Details

374 of 508 branches covered (73.62%)

Branch coverage included in aggregate %.

57 of 67 new or added lines in 1 file covered. (85.07%)

1 existing line in 1 file now uncovered.

4256 of 5348 relevant lines covered (79.58%)

2292.38 hits per line