Skip to content

KAFKA-16245: Improve reliability of short initialization timeout tests - #23230

Merged
m1a2st merged 2 commits into
apache:trunkfrom
AndrewJSchofield:KAFKA-16245-2
Aug 26, 2026
Merged

KAFKA-16245: Improve reliability of short initialization timeout tests#23230
m1a2st merged 2 commits into
apache:trunkfrom
AndrewJSchofield:KAFKA-16245-2

Conversation

@AndrewJSchofield

@AndrewJSchofield AndrewJSchofield commented Aug 21, 2026

Copy link
Copy Markdown
Member

The DescribeConsumerGroupTest.test...WithShortInitializationTimeout
tests are flaky. They have an inherent race condition, which generally
works. However, they rely on admin client calls timing out before the
consumer offsets topic has auto-created. Prior to this PR, the test
cases internally iterated over the CONSUMER and CLASSIC group types, and
tried to get both group protocols to fail with a timeout before the
topic had initialized. Occasionally this race was lost and the test
failed.

I considered using a fresh cluster for each group type and running the
tests twice. However, it seems that there's little benefit testing two
group types, so I just changed the tests to use the CONSUMER group type
only.

Reviewers: Ken Huang s7133700@gmail.com

@github-actions github-actions Bot added tools tests Test fixes (including flaky tests) labels Aug 21, 2026

@m1a2st m1a2st left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this patch. I have two minor comments. We can address these in a follow-up patch as well.

  1. The rationale here seems to be that both group protocols produce identical assertions. If so, it might be worth applying the same cleanup to some of the other tests in this file as well.

  2. Unrelated to this PR, but I noticed that testDescribeSimpleConsumerGroup iterates over the supported group protocols while always creating the consumer with CLASSIC. As a result, on a cluster that supports both protocols, the exact same CLASSIC-only scenario is executed twice, differing only in the topic and group names.

@AndrewJSchofield

Copy link
Copy Markdown
Member Author

Thanks for this patch. I have two minor comments. We can address these in a follow-up patch as well.

  1. The rationale here seems to be that both group protocols produce identical assertions. If so, it might be worth applying the same cleanup to some of the other tests in this file as well.
  2. Unrelated to this PR, but I noticed that testDescribeSimpleConsumerGroup iterates over the supported group protocols while always creating the consumer with CLASSIC. As a result, on a cluster that supports both protocols, the exact same CLASSIC-only scenario is executed twice, differing only in the topic and group names.

Thanks for reviewing the PR.

  1. My initial aim is to get the tests reliable because green builds are great. That's why I targeted these ones to start with, and it didn't seem to me that what they are testing is type-dependent.

  2. That makes no sense at all. I will address this one too.

@m1a2st m1a2st left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM

@m1a2st
m1a2st merged commit 191a7fb into apache:trunk Aug 26, 2026
22 checks passed
@AndrewJSchofield
AndrewJSchofield deleted the KAFKA-16245-2 branch August 26, 2026 07:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tests Test fixes (including flaky tests) tools

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants