Skip to content

RPC error response object violates JSON-RPC 2.0 specification #289

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

Closed
jorisbontje opened this issue Feb 3, 2015 · 5 comments
Closed

RPC error response object violates JSON-RPC 2.0 specification #289

jorisbontje opened this issue Feb 3, 2015 · 5 comments

Comments

@jorisbontje
Copy link

http://www.jsonrpc.org/specification#error_object

5.1 Error object
When a rpc call encounters an error, the Response Object MUST contain the error member with a value that is a Object with the following members:

code
A Number that indicates the error type that occurred.
This MUST be an integer.
message
A String providing a short description of the error.
The message SHOULD be limited to a concise single sentence.
data
A Primitive or Structured value that contains additional information about the error.
This may be omitted.
The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.).

However the RPC currently returns an object lacking the message and code attributes:

2015/02/03 10:20:21 [RPC] Sending payload: {"id":0,"jsonrpc":"2.0","error":true,"errortext":"Error: Could not parse request"}
@fjl
Copy link
Contributor

fjl commented Feb 3, 2015

@tgerring the standard library jsonrpc implementation handles this correctly.

@tgerring
Copy link
Contributor

tgerring commented Feb 3, 2015

@fjl I'm not sure how we'd use the standard library to meet our needs in this case since the rpc package maps objects in the format of "Object.Method", differing from the style defined at https://github.com/ethereum/wiki/wiki/Generic-JSON-RPC

If it's possible, we can switch code over.

@tgerring tgerring mentioned this issue Feb 3, 2015
@fjl
Copy link
Contributor

fjl commented Feb 3, 2015

Damn. I thought there was a way around it. Nevermind then.

@tgerring
Copy link
Contributor

tgerring commented Feb 3, 2015

Updates to JSON responses made in 55ed0ff

@jorisbontje
Copy link
Author

Fixed

ngtuna added a commit to ngtuna/tomochain that referenced this issue Nov 21, 2018
update devnet genesis, include DV and slashing
Zergity added a commit to Zergity/go-ethereum that referenced this issue Apr 28, 2020
maoueh pushed a commit to streamingfast/go-ethereum that referenced this issue Aug 13, 2021
* refactor: split out single-iteration of sequencer loop

* refactor: split out single-iteration of verifier loop and re-enable test

* refactor: extract context update to separate function

* chore: return nil instead of error in latest tx queries

If we return an error, this will clutter error logs when the
sequencer/verifier is booting up

* fix: return error instead of skipping inside of loop

Previously, we would continue if an error was returned when:
1. getting a transaction (or if there was no transaction)
2. getting an enqueued transaction (or if there was no enqueued transaction)
3. applying a transaction

Instead of silently skipping, we must always return an error.
There should be an explicit assumption on the DTL, that it will have
no gaps and that it can reliably provide us the data between [start, end].
If not, there should be an error since we want to favor safety over liveness.

* chore: test pre-state and log.Debug instead of error
weiihann pushed a commit to weiihann/go-ethereum that referenced this issue Nov 30, 2023
sduchesneau pushed a commit to streamingfast/go-ethereum that referenced this issue Feb 26, 2024
Handle INVALID opcode in the flatCallTracer
luanxu-mxc pushed a commit to MXCzkEVM/mxc-geth that referenced this issue Sep 2, 2024
* feat(consensus): update `ValidateAnchorTx`

* feat(consensus): update `ValidateAnchorTx`
s1na pushed a commit to s1na/go-ethereum that referenced this issue Dec 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants