Supply & parse receiver response errors #110

DanGould · 2023-10-17T22:50:39Z

jbesraa · 2023-10-19T14:29:30Z

payjoin/Cargo.toml

@@ -22,6 +22,8 @@ bitcoin = { version = "0.30.0", features = ["base64"] }
 bip21 = "0.3.1"
 log = { version = "0.4.14"}
 rand = { version = "0.8.4", optional = true }
+serde = { version = "1.0.107", features = ["derive"] }


do we have better options than serde?
I have some reservations in adding it to such a project for the following reasons:

a couple of months ago this thing happened https://www.bleepingcomputer.com/news/security/rust-devs-push-back-as-serde-project-ships-precompiled-binaries/
it was eventually reverted but it is a red flag

serde does a great job but it also makes compilation/building the project much slower

We only need to parse and produce 2 lines of valid json without anything fancy like nesting. What do you suggest as an alternative, and why?

The json crate would require us to lift more for deserialization but is lightweight in comparison to serde https://github.com/maciejhirsz/json-rust

We should pay attention to how rust-bitcoin desides to handle this even though their use case is optional vs. protocol-critical here rust-bitcoin/rust-bitcoin#2009

we could consider https://github.com/rhysd/tinyjson

its well documented, tested and the code is quite readable

its really tiny(we can also clone it into payjoin repo and strip out any code we dont need, we just parse string really)

disadvantages: last update was a few months ago, but that's not necessarily a red flag

I think optimal scenario is to clone tinyjson, clean it up so it has only functionality we need and maintain it ourselves.

maybe we can also leave serde and put it behind a flag for now.

it really depends on how fast we want this pr to be merged

*I am intentionally not mentioning performance here because we are not dealing with large/nested json structures so that should be a problem

regarding json-rust, its not maintained and the last update was 3 years ago, an alternative crates were developed(like rust-json)

I think optimal scenario is to clone tinyjson, clean it up so it has only functionality we need and maintain it ourselves.

This is definitely overkill to parse 4 lines of JSON that should only ever encode / decode strings with errorCode and message fields. We could honestly write an even simpler parser and forego a JSON dependency without a problem.

We might miss some edge cases, but we could simplify ser/de do the following

fn serialize_error(error_code: &str, message: &str) -> String { format!(r#"{{"errorCode": "{}", "message": "{}"}}"#, error_code, message) }

above is how we've already been serializing errors

fn deserialize_error(json: &str) -> Option<(&str, &str)> { let error_code_start = json.find("\"errorCode\": \"")? + "\"errorCode\": \"".len(); let error_code_end = json.find("\", \"message\": \"")?; let message_start = error_code_end + "\", \"message\": \"".len(); let message_end = json.rfind("\"}")?; let error_code = &json[error_code_start..error_code_end]; let message = &json[message_start..message_end]; Some((error_code, message)) }

DanGould · 2023-10-20T18:56:05Z

I started to add tinyjson but got stuck deserializing. The value["index"] syntax will panic and we need it too return errors. The latest source provides .query() but it's not released yet

jbesraa · 2023-11-10T09:30:55Z

payjoin-cli/src/app.rs

+            log::error!("Response contains error: {}", e);
+            log::debug!("Response contains error: {:?}", e);


Maybe we could have the definition of debug execute all the logs of error as well and then we wont have to add double log lines.
for example, if we have these levels of logs:

Debug <- show everything Trace is showing + some more logs

Trace <- show everything Error is showing + some more logs

Error <- show only errors

jbesraa · 2023-11-10T09:31:40Z

payjoin/src/send/error.rs

+impl WellKnownError {
+    pub fn from_str(s: &str) -> Option<Self> {
+        match s {
+            "unavailable" => Some(WellKnownError::Unavailable),


validated the errors and their description against https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-well-known-errors
looks good!

jbesraa · 2023-11-10T09:32:27Z

payjoin/src/send/error.rs

+        use tinyjson::{JsonParser, JsonValue};
+
+        let parsed: JsonValue = json.parse().unwrap();
+        //.unwrap_or_else( |_| ResponseError::Validation(InternalValidationError::Parse.into()));


commented code

jbesraa · 2023-11-10T09:33:50Z

payjoin/src/send/error.rs

@@ -210,3 +210,102 @@ impl std::error::Error for CreateRequestError {
 impl From<InternalCreateRequestError> for CreateRequestError {
    fn from(value: InternalCreateRequestError) -> Self { CreateRequestError(value) }
 }
+
+pub enum ResponseError {
+    // Well known errors with internal message for logs as String


should we add a bit more info here and maybe link to bip78 for reference?
also, should we use /// in the comments so it shows also on docs.rs ?

jbesraa · 2023-11-10T09:34:24Z

payjoin/src/send/error.rs

+    // Don't display unknowns to end users, only debug logs
+    Unrecognized(String, String),
+
+    Validation(ValidationError),


missing some docs here, I feel that Validation is quite broad

jbesraa · 2023-11-10T09:37:47Z

ah just saw your comment regarding tinyjson, how do you want to proceed with that?

DanGould · 2023-11-28T18:46:31Z

closed for #120

supersedes #110 resolves #53

DanGould force-pushed the well-known-errors branch from ed3f782 to 51e7fd8 Compare October 18, 2023 00:14

jbesraa reviewed Oct 19, 2023

View reviewed changes

DanGould added 2 commits October 19, 2023 10:45

Parse receiver response errors

2fbc22c

Internal error returns Unavailable

f535666

DanGould force-pushed the well-known-errors branch from 51e7fd8 to f535666 Compare October 19, 2023 14:45

DanGould mentioned this pull request Oct 19, 2023

Send payjoin MutinyWallet/mutiny-node#647

Merged

2 tasks

[draft] tinyjson

210ca40

jbesraa reviewed Nov 10, 2023

View reviewed changes

DanGould assigned jbesraa Nov 13, 2023

jbesraa mentioned this pull request Nov 28, 2023

Supply & parse receiver response errors #120

Merged

DanGould closed this Nov 28, 2023

DanGould added a commit that referenced this pull request Dec 27, 2023

Supply & parse receiver response errors (#120)

8ffa8ef

supersedes #110 resolves #53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Supply & parse receiver response errors #110

Supply & parse receiver response errors #110

DanGould commented Oct 17, 2023 •

edited

Loading

jbesraa Oct 19, 2023 •

edited

Loading

DanGould Oct 19, 2023 •

edited

Loading

jbesraa Oct 20, 2023

jbesraa Oct 20, 2023

DanGould Oct 20, 2023

DanGould Oct 20, 2023

DanGould commented Oct 20, 2023

jbesraa Nov 10, 2023

jbesraa Nov 10, 2023

jbesraa Nov 10, 2023

jbesraa Nov 10, 2023

jbesraa Nov 10, 2023

jbesraa commented Nov 10, 2023

DanGould commented Nov 28, 2023

		log::error!("Response contains error: {}", e);
		log::debug!("Response contains error: {:?}", e);

Supply & parse receiver response errors #110

Supply & parse receiver response errors #110

Conversation

DanGould commented Oct 17, 2023 • edited Loading

jbesraa Oct 19, 2023 • edited Loading

Choose a reason for hiding this comment

DanGould Oct 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanGould commented Oct 20, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbesraa commented Nov 10, 2023

DanGould commented Nov 28, 2023

DanGould commented Oct 17, 2023 •

edited

Loading

jbesraa Oct 19, 2023 •

edited

Loading

DanGould Oct 19, 2023 •

edited

Loading