Browse Source
✅ MAJOR SUCCESS - Member ID Consistency Fixed! 🔧 TECHNICAL FIXES: - Deterministic member ID using SHA256 hash of client info ✅ - Member reuse logic: check existing members by clientKey ✅ - Consistent member ID across JoinGroup calls ✅ - No more timestamp-based random member IDs ✅ 📊 EVIDENCE OF SUCCESS: - First call: 'generated new member ID ...4b60f587' - Second call: 'reusing existing member ID ...4b60f587' - Same member consistently elected as leader ✅ - kafka-go no longer disconnects after JoinGroup ✅ 🎯 ROOT CAUSE RESOLUTION: The issue was GenerateMemberID() using time.Now().UnixNano() which created different member IDs on each call. kafka-go expects consistent member IDs to progress from JoinGroup → SyncGroup. 🚀 BREAKTHROUGH IMPACT: kafka-go now progresses past JoinGroup and attempts to fetch messages, indicating the consumer group workflow is working! NEXT: kafka-go is now failing on Fetch API - this represents major progress from JoinGroup issues to actual data fetching. Test result: 'Failed to consume message 0: fetching message: context deadline exceeded' This means kafka-go successfully completed the consumer group coordination and is now trying to read actual messagespull/7231/head
2 changed files with 34 additions and 8 deletions
Loading…
Reference in new issue