发布

  • [NA] [BE] fix: stop BaseRedisSubscriberTest.shouldRemoveConsumerOnStop flaking (#6754)

    frostbyte_neo 发布于 2026-05-18 16:14:28 +00:00

    • [NA] [BE] fix: stop BaseRedisSubscriberTest.shouldRemoveConsumerOnStop flaking

    BaseRedisSubscriber.stop() calls removeConsumer().block(longPollingDuration)
    to wait for Redis to remove the consumer from the group, then disposes
    consumerScheduler. If the block timeout fires first, the in-flight
    removeConsumer call is cancelled by the disposal and the consumer is left
    behind. TestStreamConfiguration had longPollingDuration = 100ms, which is
    tighter than Redis-container response under load (CI or otherwise), so the
    test failed deterministically locally (8/8) and intermittently in CI.

    • Bump test longPollingDuration to 2s (prod default is 5s; this keeps tests
      fast for the happy path while matching prod's headroom ratio).
    • Handle the now-reachable empty-group case: stream.listConsumers(...) returns
      an empty Mono (block() -> null) when the group has no consumers, so wrap
      with blockOptional().orElse(List.of()).

    Stress-verified locally: 10/10 passing after fix (was 0/8 before).

    • fix(tests): use 500ms longPollingDuration to keep both LifecycleTests and RetryTests green

    The previous 2s bump fixed shouldRemoveConsumerOnStop but extended the
    read-loop cycle past the 2s test budget, so autoClaim never fired and
    shouldAckAndRemoveAfterMaxRetries / shouldHandleMixedSuccessRetryableAnd-
    NonRetryableMessagesInSameBatch broke instead.

    longPollingDuration is the XREADGROUP BLOCK timeout AND stop()'s removeConsumer
    block timeout, so it has to be:

    • long enough that Redis-container response under load doesn't exceed it
      (or stop() cancels the in-flight removal on scheduler disposal), and
    • short enough that one chain finishes inside the 2s test wait so autoClaim
      (gated by claimIntervalRatio polls) actually runs.

    500ms gives ~5x headroom for Redis response and keeps the cycle short enough:
    with claimIntervalRatio=2 (the retry-tests override), autoClaim fires around
    t ~= 1.2s, well inside 2s.

    Stress-verified locally: 10/10 BUILD SUCCESS running both LifecycleTests and
    RetryTests nested classes.

    下载附件