Browse Source
🔍 CRITICAL FINDINGS - Consumer Group Protocol Analysis ✅ CONFIRMED WORKING: - FindCoordinator API (key 10) ✅ - JoinGroup API (key 11) ✅ - Deterministic member ID generation ✅ - No more JoinGroup retries ✅ ❌ CONFIRMED NOT WORKING: - SyncGroup API (key 14) - NEVER called by kafka-go ❌ - Fetch API (key 1) - NEVER called by kafka-go ❌ 🔍 OBSERVED BEHAVIOR: - kafka-go calls: FindCoordinator → JoinGroup → (stops) - kafka-go makes repeated Metadata requests - No progression to SyncGroup or Fetch - Test fails with 'context deadline exceeded' 🎯 HYPOTHESIS: kafka-go may be: 1. Using simplified consumer protocol (no SyncGroup) 2. Expecting specific JoinGroup response format 3. Waiting for specific error codes/state transitions 4. Using different rebalancing strategy 📊 EVIDENCE: - JoinGroup response: 215 bytes, includes member metadata - Group state: Empty → PreparingRebalance → CompletingRebalance - Member ID: consistent across calls (4b60f587) - Protocol: 'range' selection working NEXT: Research kafka-go consumer group implementation to understand why SyncGroup is bypassed.pull/7231/head
2 changed files with 11 additions and 5 deletions
Loading…
Reference in new issue