Don't panic, handle errors. #57
Conversation
DanGould
force-pushed
the
error
branch
2 times, most recently
from
de06ab1 to
57e8932
Compare
| *not_found.status_mut() = StatusCode::NOT_FOUND; | ||
| Ok(not_found) | ||
| let headers = Headers(req.headers().to_owned()); | ||
| let query = { |
There was a problem hiding this comment.
I couldn't find a cleaner way of getting around not having Copy..
| let body = req.into_body(); | ||
| let bytes = hyper::body::to_bytes(body).await?; | ||
| dbg!(&bytes); // this is correct by my accounts | ||
| let reader = &*bytes; |
There was a problem hiding this comment.
Do we actually want to dbg! these bytes?
There was a problem hiding this comment.
It has let us check the original PSBT in the past. Of little use here. We could introduce the log crate to show debug/warn/errors logging soon
There was a problem hiding this comment.
removed it for this pr
| let resp = Response::new(Body::from(self.to_string())); | ||
| let (mut parts, body) = resp.into_parts(); | ||
|
|
||
| // TODO respond with well known errors as defined in BIP-0078 |
There was a problem hiding this comment.
Will this also give us more informative errors on most senders?
There was a problem hiding this comment.
The only difference to start would be UI would say
"not-enough-money | The receiver added some inputs but could not bump the fee of the payjoin proposal."
or
"original-psbt-rejected | The receiver rejected the original PSBT. "
otherwise the spec says to put errors into logs only. This becomes more useful when we're using our own sender because we can show can decide to propagate new well-known errors into our UIs.
|
Looks good to me! Great stuff. Yep expect sounds right to use |
Co-authored-by: evanlinjin <hello@evanlinjin.me>
Co-authored-by: evanlinjin <hello@evanlinjin.me>
Fix unwrap()s and panic!()s by introducing new LndError variants.
Fix "
unwrap()s everywhere" disclaimer by handling errors. They still need to propagate to the UI.HttpErrors still need to be returned with proper HTTP status codes
There are still 2 unwraps on mutex locks
let mut pj_by_spk = self.pjs.lock().unwrap();which should probably panic withexpectinstead. What do you think?I also need to add @evanlinjin as co-author of the HttpError. Work from #10 finally making it in!
fix #33
#50 could be fixed in this PR by pushing an update to the front end. but this at least responds by passing the error to the sender where they should end up in logs