Skip to content

KAFKA-20713: Lower level for client log on self-healing session not found#22617

Open
lianetm wants to merge 4 commits into
apache:trunkfrom
lianetm:lm-fetch-log
Open

KAFKA-20713: Lower level for client log on self-healing session not found#22617
lianetm wants to merge 4 commits into
apache:trunkfrom
lianetm:lm-fetch-log

Conversation

@lianetm

@lianetm lianetm commented Jun 18, 2026

Copy link
Copy Markdown
Member

Lower to DEBUG and update message for the fetch session not found
(evicted) scenario. The previous INFO log reported this as an error, but
on the client side it is self-healing and not actionable.

Fetch sessions are managed on the broker, which already exposes the
visibility needed (metrics and logs) to detect this situation and
correct it (broker configs for fetch session cache)

Reviewers: Andrew Schofield aschofield@confluent.io

@github-actions github-actions Bot added clients small Small PRs labels Jun 18, 2026
if (response.error() != Errors.NONE) {
log.info("Node {} was unable to process the fetch request with {}: {}.",
node, nextMetadata, response.error());
if (response.error() == Errors.FETCH_SESSION_ID_NOT_FOUND) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do we also need to handle INVALID_FETCH_SESSION_EPOCH? I think that this in principle can happen when a network connection is lost and reconnected, and the recovery action is the same.

@lianetm lianetm Jun 18, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

updated.

The invalid epoch should not be as common I would imagine but still makes sense to log as in session not found as the handling and impact on the client is the same (none, self-healing). I imagine it's less common because the consumer sends a full fetch request upon errors, so would start a new session even if it carries an old epoch it seems (just sharing because I didn't know myself this on fetch, same approach in the consumer and heartbeats: full request upon errors with the GC). Btw, I ended up consolidating all other errors like the invalid epoch (all are top-level errors with that are handled the same: re-send full fetch with nextCloseExistingAttemptNew)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants