[Sequencer] - fake receipt for OOC transaction

[hexoscott]

If you send a transaction that causes an OOC you are never able to get a receipt for this. We need a mechanism to produce a fake receipt and share it with RPC nodes (or at lease the one that made the initial request), or alternatively check on the eth_sendRawTransaction call for an OOC by executing the transaction based on current state in the RPC before passing it to the sequencer for processing.

[Sharonbc01]

Hi @hexoscott can you check if this issue still needs to be resolved or if it can be closed now. Thanks

[hexoscott]

Afaik we still need this, or something like this

[Sharonbc01]

Okay thanks @hexoscott , can you please review with @mandrigin and action.
Keen to get any required last features in asap so we can thoroughly test with time on cardona assuming upgrade goes well tomorrow.

I like the approach to check for an OOG scenario earlier—during the eth_sendRawTransaction call itself but of course you guys know best!

[kstoykov]

There is work in progress regarding this one: #1016

[Sharonbc01]

Hi @kstoykov can you provide an ETA on this please?

[kstoykov]

Hi @kstoykov can you provide an ETA on this please?

I'm waiting for more information as mentioned in the PR 1016.

[hexoscott]

Just checking back in on this one @kstoykov @mandrigin. We recently made a change to ensure that an OOC transaction doesn't get automatically rejected the 2nd time it is submitted. With that in mind do we want fake receipts or not? The 2nd submission might not OOC because the world state has changed since the last submission and the TX will have the same hash.

I'm thinking we either don't want fake receipts or we need to make the transaction handling process a little more complex and check for these fake receipts and delete them every time a transaction is submitted if a fake receipt already exists for it.

[Sharonbc01]

@mandrigin Agreed to removed for mainnet milestone

[Sharonbc01]

@mandrigin do we require this for RC1?

[hexoscott]

Thoughts on this one:

• we don't want to persist these receipts, they are an exceptional case where a single TX can't fit into a batch. Instead we should hold something in memory only and it will be cleared on node restart.
• when we manually remove a TX because of this OOC we can mark the TX hash in a map in the pool
• when reading a receipt we can check this map to see if it is a problem TX and return an error about counters overflowing instead of the receipt
• if a TX is submitted with the same hash as one in the map we immediately remove it from the map. The transaction could be valid on a second run so we always want to clear this map down on re-submission

[hexoscott]

@mandrigin wdyt to the above, smaller implementation and at least gives the end use some kind of feedback to action on. It won't mess with receipts either or give any indication that the TX was handled, just an error with something meaningful.

[mandrigin]

I am descoping this one for now, let's keep the task around but I will remove the milestones