Missing transactions while looping through `eth_getBlockByNumber`

[garyorz]

Background

We are indexing transactions related to VVS-LP ownership and found that some of the owners are having negative balance. For example, this wallet 0xf6173b4D45B5052650e252499b80F02C24b9d14e, when we check its Token Transfers history, it is able to send out 1,889.994 VVS-LP in transaction 0x8228af30adf6a0bade750573b8f05d2d05472b83d4f7b9bb9a3616df6bb76477 (block number: 114172) without any transfers going in before that. By studying the balanceOf the wallet in the LP token contract, we found that the balance changed from 0 to 1889994255148034566603 at block 114161, which leads to the following bug we found.

Describe the bug

Previously, when we call eth_getBlockByNumber(114161), we are able to get 47 transactions. When we further query the last 15 transactions, 14 of them are actually in the block with height 114162 and one of them (with hash 0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b) doesn't seem to be in any block. This behaviour cannot be reproduced anymore and eth_getBlockByNumber(114161) now will return 32 transactions. (Note: this is a behaviour in cronos node 0.6.2)

However, 0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b is still missing in any blocks and we are not able to retrieve that by calling eth_getTransactionByHash. This transaction is important because it is the transaction that the wallet address mentioned above 0xf6173b4D45B5052650e252499b80F02C24b9d14e minting the VVS-LP token. So we think the eth_getBlockByNumber and eth_getTransactionByHash is missing out some transactions.

To Reproduce

1. With cronos-node 0.6.2, call eth_getBlockByNumber('0x1BDF1', true) and you will be able to see transaction 0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b at index 32
2. With cronos-node 0.6.2, call eth_getTransactionByHash('0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b') will return null
3. With cronos-node 0.6.4, call eth_getBlockByNumber('0x1BDF1', true) and the transaction will not appear anymore
4. With cronos-node 0.6.4, call eth_getTransactionByHash('0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b') will return null

Expected behavior

0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b should appear in eth_getBlockByNumber('0x1BDF1', true) and eth_getTransactionByHash('0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b') should return transaction details.

Screenshots

N/A

Additional context

See Background.

[yihuang]

https://rpc-cronos.crypto.org/block_results?height=114161

      {
        "code": 11,
        "data": null,
        "log": "out of gas in location: block gas meter; gasWanted: 0, gasUsed: 163255: out of gas",
        "info": "",
        "gas_wanted": "0",
        "gas_used": "163255",
        "events": [],
        "codespace": "sdk"
      },

There's this tx result in this block, I think it's the same issue that tx is executed successfully, but tx result is an error.

[garyorz]

The transaction details in the eth_getBlockByNumber call:

{
  "blockHash": "0xeb7ea6963227c845f4cf2c191a0debc613bd9534d17ac8634ebbaebf876fd263",
  "blockNumber": "0x1bdf1",
  "from": "0xf6173b4d45b5052650e252499b80f02c24b9d14e",
  "gas": "0x41425",
  "gasPrice": "0x48c27395000",
  "hash": "0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b",
  "input": "0xf305d7190000000000000000000000002d03bece6747adc00e1a131bba1469c15fd11e03000000000000000000000000000000000000000000000f974b043da77d48790e000000000000000000000000000000000000000000000f83562956f22c04453f000000000000000000000000000000000000000000000002c3c6c7c30c1e26e4000000000000000000000000f6173b4d45b5052650e252499b80f02c24b9d14e0000000000000000000000000000000000000000000000000000000061923bf2",
  "nonce": "0x7",
  "to": "0x145863eb42cf62847a6ca784e6416c1682b1b2ae",
  "transactionIndex": "0x20",
  "value": "0x2c7554968b0d78cb7",
  "type": "0x0",
  "v": "0x55",
  "r": "0xb0c44bee55b5bdbde7d3bd50045224392a58e8011253e5ed548a8e1529d905f",
  "s": "0x6cea99c05dc6aa8794545c3b56e7b0500dcce28b00bc92f4154bc7f68d305891"
}

[yihuang]

will be fixed by this: cosmos/cosmos-sdk#10814
since it's a breaking change, it's tricky to fix the old blocks.

[yihuang]

the fix will be released in 0.7.0 upgrade.