Skip to content

KAFKA-20828: Return should client throttle true for throttle based responses - #22912

Closed
apoorvmittal10 wants to merge 1 commit into
apache:trunkfrom
apoorvmittal10:KAFKA-20828
Closed

KAFKA-20828: Return should client throttle true for throttle based responses#22912
apoorvmittal10 wants to merge 1 commit into
apache:trunkfrom
apoorvmittal10:KAFKA-20828

Conversation

@apoorvmittal10

@apoorvmittal10 apoorvmittal10 commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

AbstractResponse.shouldClientThrottle() defaults to false, so responses
that carry a throttle_time_ms field but don't override it never trigger
client-side throttling — the client ignores the broker's throttle time
on quota violations.

This adds the missing override to every response that declares a
throttle_time_ms field, including the group heartbeat responses called
out in the JIRA (ConsumerGroupHeartbeatResponse,
ShareGroupHeartbeatResponse, StreamsGroupHeartbeatResponse).
OffsetsForLeaderEpochResponse returns version >= 2 (the version that
added the throttle field).

A regression test in RequestResponseTest asserts that every API whose
response schema has a throttle_time_ms field returns true from
shouldClientThrottle() at its latest version, so new APIs can't
reintroduce the bug.

Reviewers: Jun Rao junrao@gmail.com

@apoorvmittal10
apoorvmittal10 requested a review from junrao July 22, 2026 21:51
@github-actions github-actions Bot added triage PRs from the community clients labels Jul 22, 2026
@apoorvmittal10 apoorvmittal10 added ci-approved and removed triage PRs from the community labels Jul 22, 2026
@junrao

junrao commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

@apoorvmittal10 : Thanks for the PR. #22908 addresses the same issue and the approach seems more future proof.

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