bitcoindevkit / bdk-cli / 22332464304 / 1
11%
master: 11%

DEFAULT BRANCH: master
Ran
Files 8
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 10.89% (+0.2%) from 10.717%
22332464304.1

push

github

tvpeter 
Merge bitcoindevkit/bdk-cli#230: Refactor sync_kyoto_client

974c8d566 refactor(payjoin): add payjoin error variants to BDKCliError (Mshehu5)
35d831329 refactor(payjoin): implement polling-based monitoring with timeout (Mshehu5)
b88426adc refactor: use BlockchainClient as references (Mshehu5)
99b71fdae refactor: use handle pattern for Kyoto client (Mshehu5)

Pull request description:

  <!-- You can erase any parts of this template not applicable to your Pull Request. -->

  ### Description

  <!-- Describe the purpose of this PR, what's being adding and/or fixed -->
  This PR addresses issues encountered while implementing persistence for Payjoin specifically around the BlockchainClient only being an owned variable rather than being able to be borrowed/referenced as &Blockchainclient.
  While working on persistence I ran into problems while working on resume command which needs a blockchain client to resume states such as monitor_payjoin_proposal (receiver) and process_payjoin_proposal (sender)
  Because BlockchainClient can only be owned the current design will require a function signature of passing two separate clients to resume sender and receiver states. I initially considered splitting the command into resume_send and resume_receive but this does not fully solve the issue. In particular the sender’s process_payjoin_proposal may call broadcast_transaction and potentially broadcast multiple transactions for persisted send entries stored in the database which still requires reusable access to the client.

  This Ownership issue was previously mentioned in #200 and is also noted in a comment at the top of monitor_payjoin_proposal. It prevents the function from being able to resync multiple times and reliably detect when a transaction appears in the mempool. The root cause is that the Kyoto client Box<LightClient> is destructur... (continued)

268 of 2461 relevant lines covered (10.89%)

0.31 hits per line

Source Files on job 22332464304.1