fix: an unsupported method is reported to the page with no EIP-1193 code (4200) #279

New Issue

clawbot · 2026-08-12T13:37:15+02:00

clawbot commented

2026-08-12 13:37:15 +02:00

Found while carrying error codes through to the page for #274. Deliberately not fixed there: that unit is confined to what src/content/inpage.js surfaces, and this is in what the background produces.

handleRpc() in src/background/index.js ends with:

return { error: { message: "Unsupported method: " + method } };

No code. EIP-1193 defines 4200 ("Unsupported Method") for exactly this, and the same handler already attaches 4001, 4100 and 4902 elsewhere, so the omission reads as an oversight rather than a choice.

With #274 landed the provider passes any code through verbatim, so adding code: 4200 at that one site is the whole fix — nothing in src/content/inpage.js needs to change for it to reach the page.

Why it matters: a dApp probing for an optional method (a wallet_* capability check, a fallback chain) gets an uncoded error it cannot classify, so it cannot tell "this wallet does not implement that" from "that call failed" and cannot fall back cleanly.

Other code-less error paths in the same handler are a separate question and are not in scope here: "No accounts available", a failed proxy RPC, a failed transaction population, and an address that changed mid-preparation are all internal failures with no obvious EIP-1193 code, whereas 4200 is defined for precisely this case.

Definition of done

handleRpc() returns code: 4200 for a method it does not implement, with the message unchanged.
A test asserts the code reaches the page for an unimplemented method.
make check passes.

Found while carrying error codes through to the page for https://git.eeqj.de/sneak/AutistMask/issues/274. Deliberately not fixed there: that unit is confined to what `src/content/inpage.js` surfaces, and this is in what the background produces. `handleRpc()` in `src/background/index.js` ends with: ```js return { error: { message: "Unsupported method: " + method } }; ``` No code. EIP-1193 defines `4200` ("Unsupported Method") for exactly this, and the same handler already attaches `4001`, `4100` and `4902` elsewhere, so the omission reads as an oversight rather than a choice. With https://git.eeqj.de/sneak/AutistMask/issues/274 landed the provider passes any code through verbatim, so adding `code: 4200` at that one site is the whole fix — nothing in `src/content/inpage.js` needs to change for it to reach the page. Why it matters: a dApp probing for an optional method (a `wallet_*` capability check, a fallback chain) gets an uncoded error it cannot classify, so it cannot tell "this wallet does not implement that" from "that call failed" and cannot fall back cleanly. Other code-less error paths in the same handler are a separate question and are not in scope here: "No accounts available", a failed proxy RPC, a failed transaction population, and an address that changed mid-preparation are all internal failures with no obvious EIP-1193 code, whereas `4200` is defined for precisely this case. ## Definition of done - [ ] `handleRpc()` returns `code: 4200` for a method it does not implement, with the message unchanged. - [ ] A test asserts the code reaches the page for an unimplemented method. - [ ] `make check` passes.

clawbot referenced this issue

2026-08-12 13:38:01 +02:00

fix: carry EIP-1193 error codes through to the page (closes #274) #278

clawbot referenced this issue

2026-08-12 13:38:32 +02:00

fix: EIP-1193 error codes never reach the page — a dApp cannot detect a user rejection #274

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#279