fix: prevent updating check state before mempool insert - #25550
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #25550 +/- ##
==========================================
- Coverage 64.82% 64.81% -0.02%
==========================================
Files 810 794 -16
Lines 56157 55179 -978
==========================================
- Hits 36406 35763 -643
+ Misses 19751 19416 -335
... and 19 files with indirect coverage changes 🚀 New features to boost your workflow:
|
|
@beer-1 lint failing |
|
@aljo242 fixed! |
|
@beer-1 do you see any potential for performance overhead due to this? |
I don't think this introduce any performance degradation because it is just changing order of execution |
|
comment to prevent stale closing |
| } | ||
|
|
||
| if mode == execModeCheck { | ||
| mempoolCtx = ctx.WithMultiStore(msCache) |
There was a problem hiding this comment.
confirming my understanding here, we need to set the multistore for mempoolCtx back to to msCache since we are now not writing msCache before calling mempool.Insert when in modeCheck. So if we do not use msCache as our multistore, mmempool.Insert may operate on a stale multistore. Once we do call commitAnteCache though, we are safe to use ctx again since its ms has now been updated.
There was a problem hiding this comment.
I modified the mempool.Insert call locally to use ctx instead of mempoolCtx and all of our unit tests still passed. Could you think of a unit test that would demonstrate this ms requirement? imo its not super clear from this logic that that is required (would probably be easiest with a mock mempool and ante handler just checking values in the ms).
There was a problem hiding this comment.
@mattac21 Yes, this was a missing regression test.
I added a simple mock mempool test for this case: the ante handler writes a marker into the cached multistore, and the mock mempool's Insert asserts that the marker is visible.
With the current mempoolCtx = ctx.WithMultiStore(msCache) behavior, the test passes. If I change mempool.Insert(mempoolCtx, tx) to mempool.Insert(ctx, tx), it fails because the ante cached write is not visible to the mempool.
So I think this confirms that mempoolCtx or an equivalent context backed by msCache is required here.
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days-before-close if no further activity occurs. |
aljo242
left a comment
aljo242
left a comment
There was a problem hiding this comment.
the commitAnteCache closure adds unnecessary indirection — you need to track whether it's nil, understand it's deferred, and follow control flow across two separate blocks.
simpler restructure achieves the same thing:
if app.anteHandler != nil {
// ... ante runs against msCache ...
if mode != execModeCheck {
msCache.Write()
anteEvents = events.ToABCIEvents()
}
}
switch mode {
case execModeCheck:
err = app.mempool.Insert(ctx, tx)
if err != nil {
return gInfo, nil, anteEvents, err
}
if msCache != nil {
msCache.Write()
}
anteEvents = events.ToABCIEvents()no closure, no nil-guarded function variable. intent is explicit: write after insert for check mode, write immediately otherwise. same behavior, easier to follow.
|
the commitAnteCache closure adds unnecessary indirection — you need to track whether it's nil, understand it's deferred, and follow control flow across two separate blocks. simpler restructure achieves the same thing: if app.anteHandler != nil {
// ... ante runs against msCache ...
if mode != execModeCheck {
msCache.Write()
anteEvents = events.ToABCIEvents()
}
}
switch mode {
case execModeCheck:
err = app.mempool.Insert(ctx, tx)
if err != nil {
return gInfo, nil, anteEvents, err
}
if msCache != nil {
msCache.Write()
}
anteEvents = events.ToABCIEvents()no closure, no nil-guarded function variable. intent is explicit: write after insert for check mode, write immediately otherwise. same behavior, easier to follow. |
|
@aljo242 I agree that removing the closure makes the flow easier to follow, but I don't think we can use If we do that, So I think the safer restructure is to remove the |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days-before-close if no further activity occurs. |
3 participants
Description
Closes: #25543