-
Couldn't load subscription status.
- Fork 454
JSON RPC Error codes standardization using open-rpc extension specs #650
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
base: main
Are you sure you want to change the base?
Conversation
Error groups - Extended open-rpc spec sample implementation
Co-authored-by: Zane Starr <zcstarr@gmail.com>
|
STOP THIS A.I. SLOP NOW!!!!!!!!!!!! |
|
@sambacha this is not AI, but the culmination of many months and pretty close to a year of work, to put together a PR that can help move the ecosystem forward. If you have a criticism of the PR or something about it's content please feel free to comment with something constructive or instructive. If you don't have anything constructive to add to this conversation, please refrain from spamming the PR with comments |
meta data extension
Co-authored-by: Zane Starr <zcstarr@gmail.com>
Sync main again
Sync main again
| let extensionSpecs = []; | ||
|
|
||
| // Enhance the existing XErrorGroupsJSON extension with conditional validation for different error categories | ||
| const enhancedErrorGroupSchema = JSON.parse(fs.readFileSync('src/extensions/schemas/x-error-category-ranges.json', 'utf8')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just going to write this here for tracking purposes, that this works as a stopgap until we on the OpenRPC side have a better story for being able to apply extensions to json pointer references. If we have that then there's no need to overwrite the error group spec. You'll able to just push the two specs, here but we're still a little ways from that.
|
One thing to note, is that there is no requirement for RPC errors to be negative numbers. The JSON-RPC specification itself uses a specific range of negative numbers for its errors, but the predefined errors are just for reporting protocol-level faults. The entire range of positive integer values is available to us, so we should use it. |
| message: "EXECUTION_REVERTED" | ||
| data: "Execution is reverted by REVERT Opcode" | ||
| x-error-category: "EXECUTION_ERRORS" | ||
| - code: -31603 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this error condition exists here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#600 just merged has reverted error code = 3 which contradicts this. will this value change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will fix this as per our last RPC call, it will still be code = 3
| message: "INVALID_OPCODE" | ||
| data: "An invalid opcode was encountered during execution" | ||
| x-error-category: "EXECUTION_ERRORS" | ||
| - code: -31604 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with this one, what is the meaning of this particular code? The term "step counters" has no defined meaning in Ethereum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is ZK stack specific, I will move this out to a separate category
| - code: -32001 | ||
| message: "Resource not found" | ||
| data: "Requested resource not found" | ||
| - code: -32002 | ||
| message: "Resource unavailable" | ||
| data: "Requested resource not available" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the meaning of these two codes? These are very generic errors. I suggest we drop these, since they are not meaningful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just reflect the standard we already have
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1474.md
| - code: -31009 | ||
| message: "TX_NOT_PERMITTED" | ||
| data: "Transaction is protected and cannot be permitted for unauthorized users" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the meaning of "transaction is protected"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this description
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Co-authored-by: Sally MacFarlane <macfarla.github@gmail.com>
Goal
A standard for JSON-RPC error codes and messages across EVM-compatible chains and execution clients to improve interoperability, facilitate consistent error handling, and provide a better developer experience.
Motivation
Different Ethereum clients and EVM-compatible chains often use overlapping error codes or generic messages in their JSON-RPC API responses. This inconsistency confuses end users and developers, complicates cross-client tooling, and hampers interoperability.
Solution Abstract
Reserved ranges at a glance
GAS_ERRORSgas-error-groups.yamlEXECUTION_ERRORSexecution-errors.yamlTXPOOL_ERRORStxpool-errors.yamlZK_EXECUTION_ERRORSzk-execution-errors.yaml