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.

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

Overuse of interledger_packet::errors::ParseError #708

Closed
koivunej opened this issue Apr 15, 2021 · 0 comments · Fixed by #723
Closed

Overuse of interledger_packet::errors::ParseError #708

koivunej opened this issue Apr 15, 2021 · 0 comments · Fixed by #723

Comments

@koivunej
Copy link
Collaborator

The most popular case is ParseError::InvalidPacket which requires allocation of a String, which is most often a static string but might be result of a format!.

Some variants like ParseError::WrongType are never constructed, instead ParseError::InvalidPacket is used:

Going over through all calls to ParseError::InvalidPacket and replacing them with actual variants might be the way forward. Since ParseError is also used from other places (ccp, stream), and in relation to #704 it might be better to separate OER errors from the interledger-packet errors. This coupling currently forces the #704 case to be quite invisible since when decryption fails:

  1. It is reported as a String https://github.com/interledger-rs/interledger-rs/blob/8820e8de7f5f14644032346fce9e58ab4c20d1fd/crates/interledger-stream/src/packet.rs#L143-L144
  2. The string gets immediatedly dropped on the next callsite https://github.com/interledger-rs/interledger-rs/blob/8820e8de7f5f14644032346fce9e58ab4c20d1fd/crates/interledger-stream/src/server.rs#L285-L286

If instead interledger-stream would use smaller custom enum, like below, it would allow more clear separation for "bad packet" and "failed to decrypt".

enum InvalidPacket {
   // this assumes that interledger_packet::oer::* functionality would
   // report EncodingError instead of ParseError
   Encoding(interledger_packet::EncodingError),
   FailedToDecrypt,
}

Tagging this as breaking, as at least the interledger-packet apis are public. Inside {ccp,stream} the errors should not leak, and changes should only affect the crate-internal API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant