Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Recovering from a restart/crash where an onchain transaction is in the mempool but not yet mined #2933
We have seen many cases lately where people's nodes get a
It does not seem that we are able to recover from this at the moment as at recovering from a restart we will process all pending transactions which will essentially re-process the pending
We need to be able to handle this scenario as with the mainnet transactions taking too long to get mined this is really easy to hit.
How can we achieve this?
We should keep the transaction hash of all in flight chain transactions somewhere. Probably either in or close to the pending transactions of the ChainState. So whenever we send a transaction to the proxy the chainstate should already have it inside the pending transactions and we can add the pending transaction hash there.
Then at restarting of the node when we process the pending
I have three ideas why this could happen:
Before working on this I recommend finding out which of the above (or other) reason is causing the underpriced error.
Why not also the node crashed/restarted while an on-chain transaction is pending to be mined, and when we restart it's still pending?
That's what I think is happening. Because at that point we will try to resend the transaction once we get it out of the pending transactions at restart but we will hit the same nonce since the pending transactions are not yet mined.
I think your comment here:
hits the spot. We write
Parity has the same problem in this issue.