-
Notifications
You must be signed in to change notification settings - Fork 20.9k
eth/catalyst: force sync of txpool before clearing subpools in Rollback #31228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I think perhaps we could perform a |
833d441
to
7cbf934
Compare
Agreed, updated the commit to reflect this. |
@jwasinger any update on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that it might be more proper to make SubPool.Clear
sync any pending transactions, instead of doing this behavior in the global pool. But it's not trivial to implement and I don't think it actually adds any value (the subpools themselves aren't exposed).
Thanks for the review @jwasinger, committed your suggested change which reverted your approval. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM
lint failing. @dahu33 can you fix them? or enable contributor pushing to this branch and I can do it? |
Co-authored-by: jwasinger <[email protected]>
146d5d3
to
18faa25
Compare
My bad. Should have achieved perfection now :) |
This PR enforces a transaction pool synchronization before clearing it in the
(c *SimulatedBeacon) Rollback()
function.An alternative approach would be to modify
(p *TxPool) Clear()
to call(p *TxPool) Sync()
directly before clearing, but this PR opts to perform the synchronization explicitly inRollback()
.Issue Description
In the example below, without the enforced sync, transactions from blocks between
oldHead
andnewHead
are unexpectedly included in the newly committed block, rendering the rollback ineffective.However, introducing a
time.Sleep
betweenFork()
andRollback()
produces the expected behavior, where transactions from intermediate blocks are correctly dropped, confirming the flakey behavior: