Skip to content

Fix flaky ReaderSeekTest: avoid topic name collision between test instances - #613

Open
merlimat wants to merge 1 commit into
apache:mainfrom
merlimat:fix-reader-seek-test-topic-collision
Open

Fix flaky ReaderSeekTest: avoid topic name collision between test instances#613
merlimat wants to merge 1 commit into
apache:mainfrom
merlimat:fix-reader-seek-test-topic-collision

Conversation

@merlimat

@merlimat merlimat commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Motivation

ReaderSeekTest.testSeekToEndByTimestamp fails intermittently in CI, with all retries also failing, e.g. https://github.com/apache/pulsar-client-cpp/actions/runs/33217535403/job/99004452530:

tests/ReaderTest.cc:1001: Failure
Value of: hasMessageAvailable
  Actual: true
Expected: false

The topic name only uses a second-granularity timestamp (time(nullptr)), but gtest-parallel runs the /0 and /1 parameter instances as separate concurrent processes. When both start within the same second they share the same topic. Each process publishes its own message, so one instance's publish can land after the other instance's seek-to-end but before its hasMessageAvailable() check, which then correctly returns true and fails the assertion. In the failing job all runs shared the topic test-seek-to-end-by-timestamp-1787958423: /0 sought at 23:07:03.184, /1 published at ~.248, and /0 checked at .285 → true. Retries keep publishing to the same shared topic and poison whichever sibling is mid-seek, so the whole job fails.

testHasMessageAvailableAfterSeekToEnd has the same hazard (it also asserts exact message content after seek-to-end).

Modifications

Append GetParam() to the topic names of testSeekToEndByTimestamp and testHasMessageAvailableAfterSeekToEnd so the two parameter instances never share a topic, matching the convention already used by the other parameterized tests in this file.

…tances

testSeekToEndByTimestamp and testHasMessageAvailableAfterSeekToEnd name
their topic with only a second-granularity timestamp, but gtest-parallel
runs the /0 and /1 parameter instances as separate concurrent processes.
When both start within the same second they share the same topic, and one
instance's publish can land after the other's seek-to-end but before its
hasMessageAvailable() check, which then correctly returns true and fails
the assertion. Retries keep colliding the same way, so the whole job
fails.

Append GetParam() to the topic names so the two parameter instances never
share a topic, matching the convention used by the other parameterized
tests in this file.
@merlimat
merlimat requested a review from lhotari September 1, 2026 15:39
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.

2 participants