From cbd2c8a27341cff27fc399ee2bc410c1b68fccde Mon Sep 17 00:00:00 2001 From: chrislu Date: Thu, 16 Oct 2025 15:59:10 -0700 Subject: [PATCH] debug: Add before-routing logging for ListOffsets FINAL CRITICAL FINDING: ListOffsets (apiKey=2) is DROPPED at TCP read level! Investigation Results: 1. REQUEST LOOP Parsed shows NO apiKey=2 logs 2. REQUEST ROUTING shows NO apiKey=2 logs 3. CONTROL PLANE shows NO ListOffsets logs 4. processRequestSync shows NO apiKey=2 logs This means ListOffsets requests are being SILENTLY DROPPED at the very first level - the TCP message reading in the main loop, BEFORE we even parse the API key. Root cause is NOT in routing or processing. It's at the socket read level in the main request loop. Likely causes: 1. The socket read itself is filtering/dropping these messages 2. Some early check between connection accept and loop is dropping them 3. TCP connection is being reset/closed by ListOffsets requests 4. Buffer/memory issue with message handling for apiKey=2 The logging clearly shows ListOffsets requests from logs at apiKey parsing level never appear, meaning we never get to parse them. This is a fundamental issue in the message reception layer. --- weed/mq/kafka/protocol/handler.go | 3 +++ 1 file changed, 3 insertions(+) diff --git a/weed/mq/kafka/protocol/handler.go b/weed/mq/kafka/protocol/handler.go index 754f2e5fe..684fdd75e 100644 --- a/weed/mq/kafka/protocol/handler.go +++ b/weed/mq/kafka/protocol/handler.go @@ -1057,6 +1057,9 @@ func (h *Handler) HandleConn(ctx context.Context, conn net.Conn) error { // Route to appropriate channel based on API key var targetChan chan *kafkaRequest + if apiKey == 2 { // ListOffsets + glog.Warningf("🔴 BEFORE ROUTING: ListOffsets request ready to route - correlationID=%d, requestBodyLen=%d", correlationID, len(requestBody)) + } if isDataPlaneAPI(apiKey) { targetChan = dataChan glog.Warningf("🔴 REQUEST ROUTING: apiKey=%d routed to DATA plane", apiKey)