test(scenario): tolerate at-least-once duplicate delivery during sharded pub/sub handoff#3345
Open
kiryazovi-redis wants to merge 1 commit into
Open
Conversation
…ate handoff The OSS smart-client-handoff scenario subscribes the new pub/sub node before destroying the old one, so a broadcast message can be delivered by both connections during the overlap window (intentional at-least-once). The during-migrate assertion `received <= sent` encoded an at-most-once invariant that this handoff deliberately does not provide, producing spurious `received (N) should be <= sent (M)` failures. Assert instead that delivery continued through the handoff; the strict, loss-free `received === sent` check after migration is unchanged.
empirehub01
approved these changes
Jul 20, 2026
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
2 participants
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.
Summary
The OSS sharded pub/sub smart-client-handoff scenario asserted at-most-once
delivery (
received <= sent) for the window in which slots are being migrated.Sharded pub/sub delivery across a slot migration / connection handoff is
at-least-once: while the client re-establishes its shard subscriptions on the
new owner, a small number of messages can be delivered more than once. That is
expected, correct behaviour, so the strict
received <= sentassertion made thetest fail intermittently.
What changed
being received on every channel) instead of asserting
received <= sent.migration completes, so genuine message loss/duplication outside the handoff
window is still caught.
Only test code is touched; no client/runtime behaviour changes.
Test plan
migrate/handoff path.
Prepared with AI assistance and reviewed under my account.
Note
Low Risk
Test-only assertion and comment updates; no production code paths affected.
Overview
Fixes flaky OSS smart-client handoff E2E tests that treated at-least-once pub/sub delivery during slot migration as a failure.
While publishing through a migrate/handoff, assertions no longer require
received <= sent(which breaks when the client briefly subscribes on the new shard owner before tearing down the old connection and duplicates are expected). They now only check that each channel keeps receiving messages during the migration window, with inline comments documenting that behavior.Strict
received === sentchecks after migration (post-stabilize publish burst) are unchanged, so real loss or bad duplication outside the handoff window is still caught. Test-only change insmart-client-handoffs-oss.e2e.ts; no client/runtime changes.Reviewed by Cursor Bugbot for commit 0757f68. Bugbot is set up for automated code reviews on this repo. Configure here.