Skip to content

Prune the request pool after a reconfig - #699

Merged
pfi79 merged 1 commit into
hyperledger:mainfrom
HagarMeir:prune-pool-after-reconfig
Oct 10, 2026
Merged

pfi79 merged 1 commit into
hyperledger:mainfrom
HagarMeir:prune-pool-after-reconfig

Conversation

@HagarMeir

Copy link
Copy Markdown
Contributor

Fixes #698

Problem

After a reconfig, requests that the new config makes invalid stayed in the request pool:

  • The new controller created by Consensus.reconfig sets its verification sequence from the verifier in Start. The application has already applied the new config by then, so MaybePruneRevokedRequests never sees a change.
  • The prune at the end of the old controller's decide is usually skipped, because the controller is already closed and decide returns early.

Fix

Prune the pool unconditionally in Consensus.reconfig, after the new components are created and before they are started. At that point all components are stopped and pool timers are paused, so the prune doesn't race with batching or timers. The verifier already reflects the new config. The existing MaybePruneRevokedRequests calls are unchanged.

Test

TestPoolPrunedAfterReconfig: a follower holds a request in its pool, and a long forward timeout keeps the request from being forwarded to the leader. A reconfig is then committed, and the test app revokes the request's client when it delivers the reconfig. The test checks that the follower's pool ends up empty, and that a new request is still delivered afterwards.

The test app gets an opt-in clientsToRevoke list. When a reconfig is delivered, the listed clients' requests fail VerifyRequest and the verification sequence is bumped. Existing tests don't set the list, so their behavior is unchanged.

Without the fix the test failed 5/5 runs. With the fix it passed 20/20 runs under -race.

🤖 Generated with Claude Code

After a reconfig the new controller initializes its verification
sequence from the verifier, which already reflects the new config,
so MaybePruneRevokedRequests never detects the change. The prune in
the old controller's decide is usually skipped because the controller
is closed by then. As a result, requests revoked by the new config
remained in the pool.

Prune the pool unconditionally in Consensus.reconfig, after the new
components are created and before they are started.

Fixes hyperledger#698

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: Hagar Meir <hagar.meir@ibm.com>
@pfi79
pfi79 merged commit f44fcdf into hyperledger:main Oct 10, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Request pool is not reliably pruned of revoked requests after a reconfig

2 participants