fix(core/txpool): key Osaka gas-cap discard off the reached pool head - #2521
fix(core/txpool): key Osaka gas-cap discard off the reached pool head#2521gzliudan wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Fixes Osaka gas-cap transaction removal after aborted legacy txpool resets by checking the pool’s actual head transition.
Changes:
- Discards over-cap transactions only after a successful Osaka boundary crossing.
- Adds configurable test block gas limits.
- Adds coverage for successful, aborted, recovered resets and announcements.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
core/txpool/legacypool/legacypool.go |
Keys Osaka cleanup to actual pool heads. |
core/txpool/legacypool/legacypool_test.go |
Adds Osaka reset and announcement tests. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
0c23a3a to
e84fc4e
Compare
ead78e7 to
e2235e2
Compare
gzliudan
changed the title
79b771a to
7303a56
Compare
When a reorg reset crosses the Osaka fork boundary, the pool discards the transactions whose gas limit exceeds the cap. The check keyed off the heads the reset was asked to move between, which an aborted reset never reaches, so the pool could drop transactions still valid under the head it stays on. A coalesced pending reset is unreliable the other way: the reorg loop replaces only the new head, leaving a stale old head that makes the discard skip although the pool crossed the fork. Key the discard off the heads the pool actually lands on instead, and run it after the reset so over-cap transactions the reset reinjects are covered too. This deliberately diverges from upstream geth, which keys the discard off the requested heads before the reset. The Osaka tests need pools whose block gas limit exceeds the transaction gas cap, so setupPoolWithConfig delegates to a chain-injection variant and osakaTestEnv owns its chain, while a stateless chain wrapper aborts state access to simulate a reset that cannot complete. Tests cover the fork crossing, the aborted reset, the coalesced reset with a stale old head, and the announcements for discarded transactions queued through the reorg loop.
7303a56 to
4f976e7
Compare
Proposed changes
When a reorg reset crosses the Osaka fork boundary, the pool discards the transactions whose gas limit exceeds the cap. The check keyed off the heads the reset was asked to move between, which an aborted reset never reaches, so the pool could drop transactions still valid under the head it stays on. A coalesced pending reset is unreliable the other way: the reorg loop replaces only the new head, leaving a stale old head that makes the discard skip although the pool crossed the fork.
Key the discard off the heads the pool actually lands on instead, and run it after the reset so over-cap transactions the reset reinjects are covered too. This deliberately diverges from upstream geth, which keys the discard off the requested heads before the reset.
The Osaka tests need pools whose block gas limit exceeds the transaction gas cap, so setupPoolWithConfig delegates to a chain-injection variant and osakaTestEnv owns its chain, while a stateless chain wrapper aborts state access to simulate a reset that cannot complete. Tests cover the fork crossing, the aborted reset, the coalesced reset with a stale old head, and the announcements for discarded transactions queued through the reorg loop.
Compatibility
No consensus rules, block structure, wire protocol, or JSON-RPC behaviour change; only txpool fork-boundary housekeeping is affected. The divergence from upstream geth is confined to aborted or coalesced resets, where upstream's requested-head check drops transactions still valid under the actual head. A follow-up PR to upstream geth is planned, as the same defect exists there.
Types of changes
What types of changes does your code introduce to XDC network?
Put an
✅in the boxes that applyImpacted Components
Which parts of the codebase does this PR touch?
Put an
✅in the boxes that applyChecklist
Put an
✅in the boxes once you have confirmed below actions (or provide reasons on not doing so) that