fix(consumer): prevent offset loss during rebalance under high load - #753
Open
nimanikoo wants to merge 1 commit into
Open
fix(consumer): prevent offset loss during rebalance under high load#753nimanikoo wants to merge 1 commit into
nimanikoo wants to merge 1 commit into
Conversation
bblankenship78
approved these changes
Jun 30, 2026
Author
|
Thanks again for approving my Kafka Flow PR. 🙌 @bblankenship78 Looks like the repository now requires 2 approving reviews before a PR can be merged. Would you mind helping me get one more approval? If there's someone you think could review it quickly, I'd really appreciate it. Thanks! |
|
ran into some issues that I think this PR would solve. Can we get this merged into kafkaflow? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes a race condition in KafkaFlow where consumers were losing track of offsets during Kafka partition rebalances under high load, causing messages to be processed more than once.
Root cause: During a rebalance (
OnPartitionsRevoked/OnPartitionsAssigned), theWorkerPoolFeederwas not stopped before theConsumerWorkerPoolwas torn down and rebuilt. This caused in-flightEnqueueAsynccalls to unblock into the newOffsetManager, which had no knowledge of the revoked partition — resulting in silent no-ops, untracked offsets, and duplicate message processing after the rebalance.Why
StopAsync()couldn't be called directly: Rebalance callbacks are invoked synchronously from withinconsumer.Consume()on the same thread the feeder is blocked on. Awaiting the feeder task there would cause a deadlock.Fix — two complementary layers:
IWorkerPoolFeeder.Cancel(), which signals cancellation without awaiting the feeder task. Both rebalance handlers now callCancel()before stopping the pool andStart()after the pool is ready.OffsetManager.Enqueue()now returnsbooland rejects messages for untracked partitions.ConsumerWorkerPool.EnqueueAsync()discards such messages instead of forwarding them to a worker without offset tracking. Kafka will replay skipped messages on the new partition owner after the rebalance completes.Fixes # (issue)
How Has This Been Tested?
5 new unit tests were added:
ConsumerManagerCooperativeStickyTests.OnPartitionsRevoked_ShouldCancelFeederBeforeWorkerPool_*ConsumerManagerCooperativeStickyTests.OnPartitionsAssigned_ShouldCancelAndRestartFeeder_*ConsumerManagerTests.OnPartitionsRevoked_ShouldCancelFeederBeforeWorkerPool_*ConsumerManagerTests.OnPartitionsAssigned_ShouldCancelAndRestartFeeder_*OffsetManagerTests.Enqueue_ForRevokedPartition_SilentlyDropsMessage_*Each rebalance test also verifies call order (
Cancel → StopPool → StartPool → Start), not just method invocation. All 124 unit tests pass.Checklist
Disclaimer
By sending us your contributions, you are agreeing that your contribution is made subject to the terms of our Contributor Ownership Statement