[BUG] API results of running multiple self-hosted auroraisnear/relayer-endpoint being different

[jun0tpyrc]

API results of running multiple self-hosted auroraisnear/relayer-endpoint being different , e.g .

'{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xd8eed213e98e64482cab5736f32c04e82d5ff1cc1b992b8875948e2c825ba46d"],"id":1}'

• found it in block 0x3dd2933/0x3dd2931

'{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xb80c63794317d2ff3938a1bebfeb7e5ab282ceb404505d220c58c80f0901737e"],"id":1}'

• one get empty transactions array but one is getting non-empty result

The machine getting correct result for 0x3dd2931 (compared to explorer) is the one get wrong result for 2nd eth_getBlockByHash call & vice versa

image: auroraisnear/relayer-endpoint@sha256:938884b060b93f9600752c0d9cc6e9efa051cf47babc96af671f9b6aa620097f

[birchmd]

We're in the process of updating our relayer such that it associates each Aurora transaction with a Near receipt instead of a NEAR transaction. Without going into too many details, Aurora runs on top of Near and on Near there is a distinction between "transactions" and "receipts". The former is transformed into the latter, and the latter actually does the state changes. These are typically offset by 1 or 2 blocks. Previously we made Aurora transactions correlate with Near transactions, however that's not really right because the receipts are the state changes. Therefore in our new backend we correlate Aurora transactions with Near receipts (this has other benefits as well such as making bridge transactions more indexable). While this transition happens you may see inconsistent results. Once everything is switched over and reindexed then all sources should have the same information (including Aurorascan).

[HarmlessEvil]

What is the current status of this issue? I still can reproduce it if I compare the API response from https://mainnet.aurora.dev and the data in the explorer.

Example:

curl -s https://mainnet.aurora.dev -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc": "2.0","id":1,"method":"eth_getBlockByNumber","params":[75582269, true]}
' | jq '.result.transactions[].hash'

"0xe88df6e239a7387973e25cf6eb72de7f901152e657fcb1f17a2cd9a563b447b1"
"0x2315f7a9229cff27f01a803808dd9d6995e831446e3889b6ae3f85c3847e3289"
"0x63af0d3d312875a9c7a9e027e72e162843e42cf6b61b42b2c77c47fa192a465d"
"0xaf5ac29fa598cd34bfc5c06afead92fb957656208d82932d9d59b8f556e9078d"
"0xe1a0fb255c48b9de6d87c9dfb441eaf44de1891c39d9b4428f5940ad737bce58"
"0x23d12abba10174e4239018e6c47b6f8af6d2a5f1e0b57f46cdf55eabb685737c"

In the explorer this block has 0 transactions, but we can see that returned transactions are from previous and its parent block (75582267 and 75582268) combined

[antonpaisov]

hey @HarmlessEvil the reindexing on the aurorascan.dev side is still ongoing, soon it should be up to date. the mainnet.aurora.dev RPC response is the source of truth.

[spilin]

This repository is deprecated. If issue still persists, please reopen it on a new repository of Aurora Relayer v2.