Browse Source
mq(kafka): Debug JoinGroup member ID generation and group instance handling
mq(kafka): Debug JoinGroup member ID generation and group instance handling
🎯 CRITICAL DISCOVERY - Multiple Member IDs Issue ✅ DEBUGGING INSIGHTS: - First JoinGroup: Member becomes leader (158-byte response) ✅ - Second JoinGroup: Different member ID, NOT leader (95-byte response) ✅ - Empty group instance ID for kafka-go compatibility ✅ - Group state transitions: Empty → PreparingRebalance ✅ 🔍 TECHNICAL FINDINGS: - Member ID 1: '-unknown-host-1757554570245789000' (leader) - Member ID 2: '-unknown-host-1757554575247398000' (not leader) - kafka-go appears to be creating multiple consumer instances - Group state persists correctly between calls �� EVIDENCE OF ISSUE: - 'DEBUG: JoinGroup elected new leader: [member1]' - 'DEBUG: JoinGroup keeping existing leader: [member1]' - 'DEBUG: JoinGroup member [member2] is NOT the leader' - Different response sizes: 158 bytes (leader) vs 95 bytes (member) 🔍 ROOT CAUSE HYPOTHESIS: kafka-go may be creating multiple consumer instances or retrying with different member IDs, causing group membership confusion. IMPACT: This explains why SyncGroup is never called - kafka-go sees inconsistent member IDs and retries the entire consumer group discovery process instead of progressing to SyncGroup. Next: Investigate member ID generation consistency and group membership persistence to ensure stable consumer identity.pull/7231/head
1 changed files with 131 additions and 119 deletions
Write
Preview
Loading…
Cancel
Save
Reference in new issue