Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lianetm wants to merge 4 commits into
base: trunk
Choose a base branch
from
+10 −2
Open

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

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3fd1a1a
upd
lianetm Jun 18, 2026
bc2497b
handle invalid epoch
lianetm Jun 18, 2026
fca7987
consolidate
lianetm Jun 18, 2026
254fb08
msg
lianetm Jun 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions clients/src/main/java/org/apache/kafka/clients/FetchSessionHandler.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -526,11 +526,19 @@ private String responseDataToLogString(Set<TopicPartition> topicPartitions) {
*/
public boolean handleResponse(FetchResponse response, short version) {
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) {

@AndrewJSchofield AndrewJSchofield Jun 18, 2026

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 •
edited
Loading

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)

// Session does not exist on the broker anymore. Recoverable and self-healing, the client re-sends a full fetch request.
log.debug("Node {} returned a {} error; the fetch session {} was likely evicted from the broker's " +
"fetch session cache. Re-sending a full fetch request to establish a new session.",
node, response.error(), nextMetadata.sessionId());
nextMetadata = FetchMetadata.INITIAL;
} else {
// Other fetch-session errors (e.g. INVALID_FETCH_SESSION_EPOCH, FETCH_SESSION_TOPIC_ID_ERROR) are
// also recoverable and self-healing: the existing session is closed and a new one is re-established
// with a full fetch.
log.debug("Node {} was unable to process the fetch request with {}: {}. " +
"Re-sending a full fetch request, which closes the existing session on the broker and establishes a new one.",
node, nextMetadata, response.error());
nextMetadata = nextMetadata.nextCloseExistingAttemptNew();
}
return false;
Expand Down
Loading