Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Stabilize external error types #403

Open
spacebear21 opened this issue Nov 20, 2024 · 1 comment
Open

Stabilize external error types #403

spacebear21 opened this issue Nov 20, 2024 · 1 comment
Labels
tech debt
Milestone
payjoin-1.0

Comments

@spacebear21
Copy link
Collaborator

Currently we use opaque type externally because we aren't sure which variants will stay. Eventually these should be transparent and we can remove the Internal variants.
@DanGould DanGould mentioned this issue Jan 2, 2025
Merged
DanGould added a commit that referenced this issue Jan 2, 2025
@DanGould
Separate send version modules (part 1) (#453)
592d1d2 
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 DanGould added this to the payjoin-1.0 milestone Jan 3, 2025
@DanGould DanGould mentioned this issue Jan 4, 2025
Merged
DanGould added a commit that referenced this issue Jan 7, 2025
@DanGould
Abstract send feature error variants into separate feature-specific a…
1baa8a0 
…bstractions (#464)

This reduces the feature flag coupling toward #392 and works toward
#403.
@DanGould DanGould mentioned this issue Jan 14, 2025
Merged
DanGould added a commit that referenced this issue Jan 16, 2025
@DanGould
Separate receive::{v1,v2} error modules (#482)
e439b69 
This big move isolates v1/v2 module-specific error variants into clean
module v1/v2 error modules.

There are probably too many `impl<From>` for error variants, but this
addresses the module structure first with this PR and will be followed by
taking a magnifying glass to the way specific variants are handled.

This still also leaves `OutputSubstitutionError`, `SelectionError` and
`InputContributionError` from producing JSON error responses to cancel a
session with a v2 receiver. We're going to need to address that as part
of #403. v2 Error variants also improperly produce JSON errors, but I
think the way this was done by abusing `fmt::Display` is also an
antipattern to fix at the same time that's addressed. I'd like to leave
the JSON receiver error fixes to a follow up since what gets revealed is
potentially sensitive and we should be reviewing that change with extra
scrutiny.

See: #312, #392, #403
@DanGould DanGould mentioned this issue Jan 20, 2025
Open
@DanGould
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
tech debt
Projects
Payjoin Roadmap 📝
Status: No status
Milestone
payjoin-1.0
Development

No branches or pull requests
2 participants
@DanGould @spacebear21