#36214 test: cover cluster limits during reorgs

ReviewabilityReviewsAgreementSize
#36214 yuvicc test: cover cluster limits during reorgsReady0Crickets0 + 40 tests
  • Add functional test coverage for mempool cluster count limit enforcement during chain reorganizations
  • Ensure resurrected transactions merged with mempool descendants are correctly trimmed back to limits
  • Ready for review
  • No review verdicts recorded
  • No explicit approvals or objections yet
  • Asked to clarify what coverage this test adds over existing tests (instagibbs)
  • Suggested trimming the test down to a single mutant-killing case (sedited)
  • Requested including the killed mutant diff in a PR comment (maflcko)
  • 0 lines added or modified outside tests
  • 40 lines added or modified in tests
  • 0 lines removed in total
  • 1 files, 1 commits
Mempool and policy#10 of 14
P3 · test coverage
  • P3 because it adds regression test coverage without changing node behavior or fixing an active bug
  • Validates mempool cluster trimming when resurrected transactions reconnect with existing descendants
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Adds a functional test to `mempool_cluster.py` to verify cluster count limit handling during chain reorganizations. It creates a chain of transactions where mined parents reconnect with unconfirmed children during a reorg, asserting that the mempool evicts lower-feerate descendants to bring the oversized cluster back within limit.

Problem: Resurrecting transactions from disconnected blocks can merge them with existing mempool descendants into clusters that exceed the configured cluster limits. This reorg-driven cluster trimming path lacked dedicated functional test coverage.

Evidence of importance:

  • PR description: 'Transactions resurrected from disconnected blocks are added before their existing mempool children are linked in the transaction graph. Once those dependencies are restored, oversized clusters must be trimmed back within their configured count and size limits.'

Risk of a mistake: low (tests). Test-only change to a functional test file with no impact on node binary or consensus behavior.

Changed since the previous assessment: The current version only implements a test for the cluster count limit under the default setting, whereas the previous version was described as testing both count and size limits.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • reviewer: review of the trimmed test case and mutant diff 2026-10-28

Agreement

Crickets

no substantive comment either way

Thread notes: yuvicc updated the PR to trim the test to a single mutant-killing case per sedited's suggestion, and added the mutant diff in a comment as requested by maflcko.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
instagibbs (member)question, scopeclarify what coverage this test adds over test_chainlimits_exceeded and transaction_graph_testanswered · author clarified it exercises Trim() for count, size, and merged clusters when clusters become oversizedansweredyes2026-09-10: 'I think the only thing this test adds over `test_chainlimits_exceeded` and `transaction_graph_test` is testing the pre-existing mempool children are added back in to the clusters. Thoughts?'
Status from: 2026-09-10: yuvicc: 'These tests cover clusters that become oversized only after reconnecting existing children, exercising `Trim()` for coun'
sedited (member)suggestion, scopetrim the test down to only the case that kills a mutantfixed · fix pushed · author trimmed the test to a single mutant-killing caseansweredyes2026-10-23: 'Can you trim this down to just the case that actually kills a mutant?'
Status from: 2026-10-28: yuvicc: 'Trimmed to a single case.'
maflcko (member)suggestion, maintenanceinclude the diff of the killed mutant in a commentanswered · author updated the comment to include the mutant diffansweredyes2026-10-28: 'If there is a killed mutant, could include the diff in a comment?'
Status from: 2026-10-28: yuvicc: 'I've updated the above comment.'

Participants:

  • fanquake (member, neutral, 1 statements 2026-09-10 to 2026-09-10): tagged reviewers
  • instagibbs (member, question, 1 statements 2026-09-10 to 2026-09-10): asked what coverage the test adds over existing tests
  • sedited (member, neutral, 1 statements 2026-10-23 to 2026-10-23): suggested trimming tests to only mutant-killing cases
  • maflcko (member, neutral, 1 statements 2026-10-28 to 2026-10-28): suggested including the diff of the killed mutant in a comment

Files

40 lines under test/bench/ci.

  • test/functional/mempool_cluster.py +40/-0

Card

The short text the ranking pass compares across PRs.

Adds functional test coverage to mempool_cluster.py for cluster mempool limits during chain reorganizations. It verifies that when resurrected transactions reconnect to existing in-mempool descendants and exceed the cluster count limit, the node trims the lowest-feerate transactions to restore limit compliance. The change is isolated to functional tests and has no dependencies.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-30T01:12, confidence high, input hash fbb2b01f688441e7
thread read through 2026-10-28 (7 statements), head 6da6d5ac69
labels: Tests

Categories

Mempool and policy

P3 · test coverage

Adds dedicated functional test coverage for reorg-driven cluster limit trimming. While it does not fix a bug or change behavior, it validates cluster limit enforcement and eviction when resurrected transactions merge with existing mempool descendants.

Membership: Adds functional test coverage in `test/functional/mempool_cluster.py` for cluster limits and eviction behavior during reorgs.

Factors: security/stability 1, bug 0, performance 0, user value 0, leverage 0