Skip to content

[fix][test] Await reader reconnect after seek() to fix flaky TopicReaderTest assertions - #26141

Merged
merlimat merged 1 commit into
apache:masterfrom
lhotari:lh-fix-flaky-topicreader-seek
Jul 2, 2026
Merged

[fix][test] Await reader reconnect after seek() to fix flaky TopicReaderTest assertions#26141
merlimat merged 1 commit into
apache:masterfrom
lhotari:lh-fix-flaky-topicreader-seek

Conversation

@lhotari

@lhotari lhotari commented Jul 2, 2026

Copy link
Copy Markdown
Member

Motivation

TopicReaderTest.testMultiReaderIsAbleToSeekWithTimeOnBeginningOfTopic fails intermittently in the
"Pulsar CI Flaky" suite with java.lang.AssertionError: expected [true] but found [false] at
assertTrue(reader.isConnected()) — observed on two unrelated PRs
(run 28608140872 and
run 28612964177).

The assertion runs immediately after seek() plus reading the messages a second time. seek() triggers
an asynchronous reconnect of the underlying consumer(s): the broker disconnects the consumer on cursor
reset so it reconnects at the new position. For a multi-topic reader,
MultiTopicsConsumerImpl.isConnected() requires all partition consumers to be connected at that
instant, so it can be transiently false right after the post-seek reads.

The assertion has always been racy, but it started failing frequently after #25338 migrated the class
to SharedPulsarBaseTest: a shared, busier broker widens the seek→reconnect window, so the latent race
now surfaces regularly.

Modifications

Await reader.isConnected() with Awaitility instead of asserting it instantly, in the three tests that
share the "seek() then assert isConnected()" pattern:

  • testReaderIsAbleToSeekWithTimeOnBeginningOfTopic
  • testMultiReaderIsAbleToSeekWithTimeOnBeginningOfTopic
  • testReaderIsAbleToSeekWithMessageIdOnMiddleOfTopic

This is a test-only change; no production code is modified.

Note: #17407 (testMultiReaderIsAbleToSeekWithTimeOnMiddleOfTopic) is a different flake — that test
has no isConnected() assertion — and is not addressed here.

Verifying this change

  • Make sure that the change passes the CI checks.

This change is a test-only rework. The three affected tests plus the other seek-with-time reader tests
pass locally with the flaky test group enabled
(-PtestGroups=flaky -PexcludedTestGroups=quarantine).

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

  • Dependencies (add or upgrade a dependency)
  • The public API
  • The schema
  • The default values of configurations
  • The threading model
  • The binary protocol
  • The REST endpoints
  • The admin CLI options
  • The metrics
  • Anything that affects deployment

…derTest assertions

Three reader tests assert reader.isConnected() immediately after seek() plus reading the messages a
second time: testReaderIsAbleToSeekWithTimeOnBeginningOfTopic,
testMultiReaderIsAbleToSeekWithTimeOnBeginningOfTopic and
testReaderIsAbleToSeekWithMessageIdOnMiddleOfTopic. seek() triggers an asynchronous reconnect of the
underlying consumer(s) -- the broker disconnects the consumer on cursor reset so it reconnects at the
new position -- and for a multi-topic reader isConnected() requires all partition consumers to be
connected at that instant, so the check can be transiently false right after the post-seek reads.

Await the condition with Awaitility instead of asserting it instantly.

The race is latent but surfaced frequently after apache#25338 migrated TopicReaderTest to
SharedPulsarBaseTest: a shared, busier broker widens the seek->reconnect window.

Assisted-by: Claude Code (Opus 4.8)
@merlimat
merlimat merged commit e0c58b0 into apache:master Jul 2, 2026
81 of 83 checks passed
@lhotari lhotari added this to the 5.0.0-M2 milestone Jul 27, 2026
lhotari added a commit that referenced this pull request Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants