payjoin / rust-payjoin / 16504632716

83%

Build Type

push

github

Committed by web-flow

Commit Message

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)

Run Details

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