ethereum / ethereum/execution-apis
graphql: standardize test outputs
- Dominant language
- Io
- Stars
- 1.1k
- Forks
- 530
- Avg merge
- 5d 8h
- Merged PRs (30d)
- 9
Description
There are multiple GraphQL hive tests where due to historical reasons 2 responses are accepted. This is unfortunate. The aim of this issue to discuss and agree on one output. The following tests have 2 acceptable responses:
- `17_eth_getBlock_byNumberInvalid.json` tries to get a block by a number that doesn't exist in the chain (88888888)
- `07_eth_gasPrice.json` accepts both `0x10` and `0x1` as valid responses
- `30_eth_getTransaction_byHash.json` this returns a transaction object. it accepts 2 responses. As far as I can tell these are the differences:
- `index` being `0` vs `0x0`. We should use `0x0` here now that all integer values are hex-encoded
- `log.index` being `0` vs `0x0`. Same as above.
- `status` being `null` vs `0x0`. I'm not sure why status should be null here. IMO we should return `0x0`.
- `33_eth_getTransactionReceipt.json` as far as I can tell only difference is `index` being `0` vs `0x0`. Should use `0x0`.
The following testcase also accepts 2 responses. Either an error, or simply a nil value. It gets the balance of an account against a block which shouldnt exist. However since we've added new block the query has now actually a correct response. It needs to be updated with another block number.
- `12_eth_getBalance_toobig_bn.json`
We need to agree what to do for 12 and 17. It boils down to this: when a resource does not exist, return null or error. IMO to stay consistent with JSON-RPC we should return null. Also this is not really an exception.
Not sure what to do for `07_eth_gasPrice`.
Contributor guide
Assessment
This issue has not been assessed yet.