`eth_getBlockByNumber` returns the L1 block, not the L2 one.

[qbzzt]

Describe the bug

When using the PRC API, retrieval of mainnet block 0x58D5D5 gives the expected result, the transaction: https://optimistic.etherscan.io/tx/5821909

However retrieval of the supposedly identical 0x58d5d5 gives us the Ethereum block: https://etherscan.io/block/5821909

To Reproduce

1. For the transaction on Optimism

   curl -H 'Content-Type: application/json' 'https://mainnet.optimism.io' -d '{"id": 1, "jsonrpc": "2.0", "method": "eth_getBlockByNumber", "params": ["0x58D5D5", true]}' | jq .result.transactions
   

2. For the block on Ethereum:

   curl -H 'Content-Type: application/json' 'https://mainnet.optimism.io' -d '{"id": 1, "jsonrpc": "2.0", "method": "eth_getBlockByNumber", "params": ["0x58d5d5", true]}' | jq .result.transactions   
   

Expected behavior

When I contact https://mainnet.optimism.io I expect to always get the Optimism chain.

Additional context

Discovered by rick from KuCoin, available on Telegram.

[mslipper]

Fixed by clearing the cache.. Working on a root cause separately.

[tarunkhasnavis]

To add more clarity, I am seeing the inverse behavior as well on a certain block. Reproduced the issue on block 0x5C4E6F where the endpoint is retrieving block on Ethereum. 0x5c4e6f retrieves L2 Block

Same Command to Reproduce:

curl --location --request POST 'https://mainnet.optimism.io' \ --header 'Content-Type: application/json' \ --data-raw '{ "jsonrpc": "2.0", "method": "eth_getBlockByNumber", "id": 1, "params": ["0x5C4E6F", true] }'

[smartcontracts]

Likely that an upstream provider is returning bad results and these results are being cached by our proxy.

[annieke]

@mslipper issue fixed, correct?

[smartcontracts]

Believed to be fixed, this was an issue with an upstream node provider. Please reopen this issue if anyone detects similar caching problems.