eth_call revert error code for Execution Errors

[MysticRyuujin]

In comparing a revert error from an eth_call between nodes, I noticed that Geth returns a generic(?) error code during a revert. Where as Nethermind returns a specific error code, and I THINK Parity/OpenEthereum is also returning the same error code as Nethermind. I'm wondering why Geth doesn't?

The Parity/OpenEthereum line referencing the specific error code is here (I think):
https://github.com/openethereum/openethereum/blob/main/rpc/src/v1/helpers/errors.rs#L41

The Nethermind line is here (I think):
https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.JsonRpc/ErrorType.cs#L91

The Geth errors.go file does not seem to have a similar error code, so I get the generic -32000:
https://github.com/ethereum/go-ethereum/blob/master/rpc/errors.go

Unfortunately, I was given this curl command from someone else while investigating an error and OpenEthereum doesn't seem to like it, so I only have outputs from Geth and Nethermind, I only looked at OpenEthereum code to see if I could find a reference to that specific error code, and I could. I cannot with Geth searching github.

Here's a sample POST body

{"jsonrpc":"2.0","method":"eth_call","params":[{"data":"0x06fdde03","to":"0x1f0d3048b3d49de0ed6169a443dbb049e6daa6ce"},{"blockHash":"0xa5626dc20d3a0a209b1de85521717a3e859698de8ce98bca1b16822b7501f74b"}],"id":1}

Here's the result from Geth, as you can see it's a generic error code:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32000,
    "message": "execution reverted"
  }
}

Here's the result from Nethermind:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32015,
    "message": "VM execution error.",
    "data": "revert"
  },
  "id": 1
}

While Google searching, I did find a stackexchange referencing the same 32015 error code, from Infura, on Kovan, so I'm guessing that Parity/OE would agree on the error code if I could query it 😄

Anyway, should the error code be 32015 for a revert of this nature?

[rjl493456442]

For the eth_call eth_estimate, they will all return a concrete revert reason if they are available. I'm not sure whether it's the specific error you want.

In your testcase, is there a concrete revert reason available? If so but Geth returns nothing, please open an issue!

[MysticRyuujin]

I'm not sure I understand the reply, I'm asking specifically about the "code" -32015 vs -32000 for an execution error.

When a revert occures, the response is an error, which contains an error code, and if you're trying to determine "did the node error out on this request? Or was this a genuine reply?" then the error code matters.

I'm not the developer of the linked dshackle application, but my assumption here is that because the error codes are different, it cannot come to a quorum and it thinks the nodes are just erroring out for different reasons.

[rjl493456442]

Yeah it's true in Geth the generic error code -32000 is returned(if the execution is failed). But in the ethereum jsonrpc doc, there is no consensus that which error code refers to the execution revert error. https://eth.wiki/json-rpc/json-rpc-error-codes-improvement-proposal

So here we return the concrete the revert reason. Developers can distinguish the error types via it?

[MysticRyuujin]

That would be fine if all of the clients were doing the same thing, but they're not. The code is different, as is the "message" and when dealing with APIs parsing a string message with a regex or whatever is far less ideal than checking the error code.

[MysticRyuujin]

It looks like maybe that error code improvement proposal would solve the problem (eventually?)

I don't know, I'm really just playing middleman here between client implementations and tools.

[holiman]

It looks like maybe that error code improvement proposal would solve the problem (eventually?)

Looks very strange to me -- it adds another layer of error codes inside the error codes. I think it would be more realistic to come to consensus about which JSON-RPC error codes in the "reserved space" of -32000 ... to use for which error.

[ligi]

It needs standartisation - ideally as an EIP. Then be added to tests.