• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

payjoin / rust-payjoin / 16504632716
83%

Build:
DEFAULT BRANCH: master
Ran 24 Jul 2025 06:18PM UTC
Jobs 1
Files 51
Run time 1min
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

24 Jul 2025 06:16PM UTC coverage: 85.783% (-0.02%) from 85.805%
16504632716

push

github

web-flow
Abstract common sender functionality, not heirarchy (#884)

`{v1,v2,multiparty}::Sender{,Builder}` types have been built off of a
heirarchy where multiparty:: has a v2:: and v2:: has a v1::, which was
done for quick convenience and not because that relationship actually
makes functional sense.

This PR is the first in a few which I believe are necessary to rectify
this distinction. It does so by drawing the separation between the
sender's `PsbtContext` checks / response processing and the
version-specific serialization for networked messaging. However, I don't
think it goes far enough.

For one, it only really rectifies this issue between v1 and v2.
Multiparty is left abstract over v2. Second, There are still distinct
SenderBuilders that can't tell whether or not they're handling a v1 or
v2 URIs. Since the information necessary to distinguish between a v1/v2
URI is in the URI itself, it seems that ought to be the first order of
business for the sender to do even before calling `SenderBuilder::new`.
The lack of this distinction leads to a
[problem](https://github.com/bitcoindevkit/bdk-cli/pull/200#issuecomment-2963733310)
with a hacky
[solution](https://github.com/bitcoindevkit/bdk-cli/pull/200#discussion_r2147355138)
where downstream users need to wait all the way until they attempt to
create a v2 request and handle an error there in order to figure out the
version. The `SenderBuilder` also ought to behave differently for each
version, and I'm not sure our current fix of #847 does this completely
(Does a v2 SenderBuilder sending to v1 URI honor pjos? it should). In
order to do so I reckon we could create an actual `PjUri` type, rather
than an alias, that enumerates over the versions when
`check_pj_supported` or its replacement is called. In order to do *that*
effectively by making sure the correct parameters are there and we're
not just switching on the presence of a fragment, I think `UrlExt` also
needs to check for the parameter presence and validit... (continued)

306 of 317 new or added lines in 5 files covered. (96.53%)

7 existing lines in 3 files now uncovered.

7862 of 9165 relevant lines covered (85.78%)

511.36 hits per line

New Missed Lines in Diff

Lines Coverage ∆ File
3
98.37
-0.08% payjoin/src/core/send/mod.rs
8
90.09
-6.11% payjoin/src/core/send/v1.rs

Uncovered Existing Lines

Lines Coverage ∆ File
1
97.62
0.0% payjoin/src/core/send/multiparty/mod.rs
1
90.84
0.2% payjoin/src/core/send/v2/mod.rs
5
90.09
-6.11% payjoin/src/core/send/v1.rs
Jobs
ID Job ID Ran Files Coverage
1 16504632716.1 24 Jul 2025 06:18PM UTC 51
85.78
GitHub Action Run
Source Files on build 16504632716
  • Tree
  • List 51
  • Changed 6
  • Source Changed 5
  • Coverage Changed 6
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #16504632716
  • 5ecfed74 on github
  • Prev Build on master (#16503850309)
  • Next Build on master (#16543289714)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc