simulators/ethereum/rpc-compat: ignore error.message and error.data

[jsvisa]

In https://hive.ethpandaops.io/#/test/generic/1757905445-5dbeb2cee294848d1644ba209e476bef?testnumber=7

the expected response:

{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -32602,
        "message": "invalid argument 0: hex string without 0x prefix"
    }
}

Actually response:

{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -32602,
        "message": "Invalid params",
        "data": "hex string without 0x prefix at line 1 column 3"
    }
}

I found some reth tests failed of the error.data not matched, from https://www.jsonrpc.org/specification#error_object, I found the error jsonrpc response will return error.message | error.data, So I think we can just ignore the error.data along with error.message, as the client maybe has it's own logic to handle error cases.

Let's focus on the error.code

[fjl]

The current comparison logic checks the error code and data must match. It already removes the error message from comparison. We need to check data and code because they are the machine-readable error outputs. Reth returning an additional message as the error data is incorrect, and they need to fix it.

[jsvisa]

@fjl thanks for the explain, but since the jsonrpc spec https://www.jsonrpc.org/specification#error_object said:

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.).

So I think that data is determined by the server, and that's why the reth not fully fixed it. We should tolerate this difference and make the error checks more robust. WDYT

[fjl]

Yes, the specification of the generic JSON-RPC protocol makes it optional. But we want the Ethereum RPC servers to agree on error data. So I am leaving this check in.