[RaphaelFakhri]

Description

After a reconfig, Consensus.reconfig prunes the request pool of requests that the new configuration makes invalid, but it checks them only with Verifier.VerifyRequest. A request that was accepted under a larger RequestMaxBytes stays in the pool.

If the reconfig also lowers RequestBatchMaxBytes below the size of that request, the request can't fit in any batch. Pool.NextRequests returns an empty batch marked as full, so the leader proposes nothing and spins in Controller.propose. The requests behind it wait until RequestAutoRemoveTimeout expires.

This change makes the reconfig prune predicate also reject requests bigger than the new RequestMaxBytes. Configuration.Validate already checks that RequestMaxBytes isn't bigger than RequestBatchMaxBytes, so every request left in the pool fits in a batch.

Testing

• New TestOversizedRequestPrunedAfterReconfig in test/reconfig_test.go: a follower holds a 2 KB request, a reconfig sets RequestMaxBytes and RequestBatchMaxBytes to 1024, and the test checks that the pool is pruned and the cluster still delivers a new request. Without the fix, the test fails because the request stays in the pool.
• go test -count 1 -race ./pkg/... ./internal/..., go test ./test/ -count=1 and golangci-lint run ./... pass.

Fixes #754

[HagarMeir]

Thanks for finding this and for the fix! The prune change looks right to me.

One request: recconfigToInt and recconfigToUint in test/reconfig.go set RequestMaxBytes from RequestBatchMaxBytes. The new test passes only because it sets both to 1024, so it doesn't really check the new predicate against RequestMaxBytes. Could you map RequestMaxBytes from its own field in both helpers?

(This review was written by Claude, an AI assistant, for Hagar Meir.)