-
Notifications
You must be signed in to change notification settings - Fork 50
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.
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
Produce receive::JsonError
accurately so that send
can properly handle it
#506
Conversation
Pull Request Test Coverage Report for Build 12966955577Details
💛 - Coveralls |
2a6a042
to
bbc06bb
Compare
Elided the explicit NOT_ENOUGH_MONEY does not return as much useful information to match feerates as I would like, but it's still on the right track and we can follow up when we classify the v2 errors. I think this is ready to go in. |
this bare url lint failure wasn't caught when I ran |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 9c770f1
Rebased to fix feerate/fee_rate conflict |
Some errors need to be returned to the sender as JSON. This concern is separate from the `Display` concern and isolated into a `JsonError:to_json` function defined in a trait.
The other codes are unknown and won't be displayed to clients.
Well-known error codes are used in both send and receive modules. Using constants makes it harder for a maintainer to accidentally produce or parse the wrong code.
Perhaps it can be extended to reveal preferences about appropriate feerates with a template, but for now this at least uses the well known error code as intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reACK a158cf2
This change could also introduce
const
values for well known error codes for bothsend
andreceive
to share to prevent slipped typos during maintenance.In reviewing the error types for v2, I realize we may want to introduce new well-known error types for the
SessionError
variants. In particular,Expired
should have a template string to return to sender clients. One other variants seems to approximately fitoriginal-psbt-rejected
payload errors (Hpke), but UnexpectedResponseSize, OhttpEncapsulation, and UnexpectedStatusCode appear to be directory issues that are unrecoverable and cannot return json to a sender.Seems like feerate configuration errors are also a special class of recoverable original-psbt-rejected error that might be worth classifying to potentially handle by clever senders.
related: #403