Stabilize external error types #403
Labels
Milestone
Comments
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: