Rework receive::v2, send::v2 submodule into additive crate::v2 and crate::v1 submodules features
#392
Labels
Milestone
Comments
DanGould
changed the title
receive::v2 submodule into crate::v2 and crate::v1 submodules feature gatedreceive::v2 submodule into additive crate::v2 and crate::v1 submodules features
DanGould
added a commit
that referenced
this issue
Jan 2, 2025
Expose descriptive, accurate send errors so that we can switch on them in implementations and mark payjoin sessions in persistent storage accurately. We only want to spawn sessions that are capable of making forward progress and drop those that cannot. Patch overview: 1. housekeeping 2. Introduce specific SenderBuilder errors 3. make CreateRequestError v2 only since v1 can only make have sender builder errors 4. separate the modules to reduce feature flags This separation is incomplete because I'm still uncertain what to do with send::ValidationError's feature gated variants. Do I make a send::ValidationError and a send::v2::ValidationError separate? How do those get handled in ResponseError? Does ResponseError get split into two versions, or do I just leave a feature gated variant? That's left for the next PR predicated on this design being an appropriate one. Note this pays back some tech debt but leaves some slop in payjoin-cli. Rather than making this PR 10 commits to review I left combining FeeRate parsing to a later PR (#452). This error puts us on the path to #392 and #403
DanGould
changed the title
receive::v2 submodule into additive crate::v2 and crate::v1 submodules featuresreceive::v2, send::v2 submodule into additive crate::v2 and crate::v1 submodules features
|
@nothingmuch I believe making |
|
although i initially started with PjUriBuilder due to #416, i it's way up my "call stack", as it were, feel free to proceed with such changes, at worst it will be a minor disruption for my changes to payjoin-cli |
spacebear21
added a commit
that referenced
this issue
Jan 8, 2025
1. kills the PjUriBuilder pattern which was a feature gating hell
2. make separate receive::{v1,v2} modules to enable error separation and
additive use
3. Pass `supported_versions` from the calling module since that's where
version comes from
4. Explicitly removes non-additive not(feature = "v2") so integration
tests can all run on --all-features
We've got a ways to go to separate modules for readability, and then to
make the features in payjoin-cli additive, but we're getting there.
This is work toward #392
This can be followed by separating the error variants into distinct
receive, receive::v1, receive::v2 types and making the v1/v2 features in
payjoin-cli additive
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't really love how the features are laid out inside receive especially. Send is not as big of a deal because the state machine has been flattened. If there were separate modules for separate features I think they'd be easier to reason about from docs.rs
Consider removing the
not(feature = v2)feature since we want to discourage its use and one can replicate v1 soverignty by running both a directory and payjoin client on the same machine. Rust features should be additive.send::{v1, v2}modules Abstract send feature error variants into separate feature-specific abstractions #464receivev1 typestate machine intoreceive::v1module with feature-gated visibilityreceive::{v1, v2}errors (related: Review usage ofcrate::receive::Error#312)optional_parameters::SUPPORTED_VERSIONSaccording to calling module, not feature flagThe text was updated successfully, but these errors were encountered: