eip_1193: entered unreachable code when canceling transaction in MetaMask

[dvec]

panicked at 'internal error: entered unreachable code: Unable to parse request response: Err(Err(Error("unknown field `stack`, expected one of `code`, `message`, `data`", line: 1, column: 90)))'

Code to reproduce this behavior:

let window = web_sys::window().expect("no window available");
let ethereum = window.get("ethereum").expect("MetaMask is not installed");
let eth = ethereum.unchecked_into::<web3::transports::eip_1193::Provider>();
let web3 = web3::Web3::new(web3::transports::eip_1193::Eip1193::new(eth)));
web3.eth().request_accounts().await;

Run and click "Cancel" when MetaMask will offer to connect your wallet to website.
The same bug appears when cancelling transaction confirmation.

[tomusdrw]

Seems like Metamask is adding additional fields to the error response. The solution would be to either:

1. Disable strict field checking (deny_unknown_fields)
2. Add stack field.

PRs welcome!

[dvec]

@tomusdrw

1. Error response struct is defined within jsonrpc crate and there is merged pr from you introducing strict struct deserializing behavior. As said in comments, if we remove deny_unknown_fields it may cause invalid responses to be parsed as correct. While JSON-RPC 2.0 specification says nothing about extra fields thereby allowing any behavior, enabled strict field checking is one more safety guaranty.

2. Error response fields is defined by JSON-RPC 2.0 specification and don't include stack field so I find it wrong to add fields that are contrary to the spec.

What I can suggest

Because this error was detected only using EIP-1193 transport we can fix it locally by defining local struct in transports::eip_1193::Provider::request_wrapped that repeats jsonrpc's Error but adds optional stack field and then converting this struct to original Error omitting stack field.

I've fixed it locally and in case of your confirmation I'll send PR.

[tomusdrw]

I've fixed it locally and in case of your confirmation I'll send PR.

That sounds great like a really good idea, and thanks for being supportive for the strict parsing in jsonrpc-core!