Skip to content

test(scenario): drive in-flight traffic during MOVING relaxed-timeout test - #3853

Open
kiryazovi-redis wants to merge 1 commit into
redis:mainfrom
kiryazovi-redis:fix/relaxed-timeout-moving-test
Open

test(scenario): drive in-flight traffic during MOVING relaxed-timeout test#3853
kiryazovi-redis wants to merge 1 commit into
redis:mainfrom
kiryazovi-redis:fix/relaxed-timeout-moving-test

Conversation

@kiryazovi-redis

@kiryazovi-redis kiryazovi-redis commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Summary

RelaxedTimeoutConfigurationTest.timeoutUnrelaxedOnMovingTest intermittently
failed with "expected at least one relaxed timeout … but was 0". The test issued
only a single reactive command around the MOVING/re-bind. When the command stack
is empty on a MOVING re-bind, the client reconnects immediately without
relaxing the timeout (by design — see MaintenanceAwareConnectionWatchdog#rebind),
so the single command observes the normal timeout and the assertion never sees a
relaxed one.

Real workloads have commands in flight across the re-bind, which is exactly when
timeout relaxation is meant to kick in.

What changed

  • Drive continuous background traffic for the duration of the maintenance
    operation so the re-bind happens with a non-empty command stack and the
    relaxation path is exercised as designed. Traffic is stopped and joined in a
    finally block.

Test-only change.

Test plan

  • RelaxedTimeoutConfigurationTest#timeoutUnrelaxedOnMovingTest against a
    server that emits MOVING notifications during a re-bind.

Prepared with AI assistance and reviewed under my account.


Note

Low Risk
Test-only change to scenario coverage; no production code paths modified.

Overview
Fixes flaky timeoutUnrelaxedOnMovingTest failures where no relaxed timeout was observed (expected at least one relaxed timeout … but was 0).

The test now runs a daemon background thread that continuously issues async SET commands (with a short sleep) for the whole maintenance window, then stops and joins it in finally. That mirrors real workloads: when the command stack is empty on a MOVING re-bind, MaintenanceAwareConnectionWatchdog#rebind reconnects without relaxing timeouts, so a single reactive command could miss the relaxation path the test is meant to validate.

Production client behavior is unchanged — test-only.

Reviewed by Cursor Bugbot for commit c227593. Bugbot is set up for automated code reviews on this repo. Configure here.

… check

timeoutUnrelaxedOnMovingTest issued a single reactive BLPOP after the MOVING
push against an otherwise idle connection. On a re-bind with an empty command
stack the client reconnects immediately without relaxing timeouts (relaxation
protects in-flight commands; see MaintenanceAwareConnectionWatchdog#rebind), so
the measured command saw the normal 30ms timeout and the "at least one relaxed
timeout during MOVING" assertion failed.

Keep continuous traffic in flight across the maintenance operation so the
re-bind is exercised as a real workload would. With traffic in flight the client
relaxes during MOVING as designed (verified locally: MOVING command times out at
the relaxed 130ms). No client change required.
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.

1 participant