Files
seaweedfs/weed
chrislu 1696ddf570 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.
2025-09-10 18:36:37 -07:00
..
2025-08-09 21:47:29 -07:00
2025-07-19 23:56:17 -07:00
2025-08-30 11:15:48 -07:00
2025-08-31 23:31:28 -07:00
2025-08-22 01:15:42 -07:00
2025-09-10 11:04:42 -07:00
2025-08-30 11:15:48 -07:00
2024-06-25 09:18:11 -07:00
2025-08-30 11:15:48 -07:00
2024-02-14 08:26:38 -08:00
2025-07-19 21:43:34 -07:00
2025-03-17 23:13:27 -07:00