CreateTopics Protocol Compliance completed:
## Implementation
- Implement handleCreateTopicsV0V1() with proper v0/v1 request parsing
- Support regular array/string format (not compact) for v0/v1
- Parse topic name, partitions, replication factor, assignments, configs
- Handle timeout_ms and validate_only fields correctly
- Maintain existing v2+ compact format support
- Wire to SeaweedMQ handler for actual topic creation
## Key Features
- Full v0-v5 CreateTopics API version support
- Proper error handling (TOPIC_ALREADY_EXISTS, INVALID_PARTITIONS, etc.)
- Partition count validation and enforcement
- Compatible with existing SeaweedMQ topic management
## Tests
- Comprehensive unit tests for v0/v1/v2+ parsing
- Error condition testing (duplicate topics, invalid partitions)
- Multi-topic creation support
- Integration tests across all API versions
- Performance benchmarks for CreateTopics operations
## Verification
- All protocol tests pass (v0-v5 CreateTopics)
- E2E Sarama tests continue to work
- Real topics created with specified partition counts
- Proper error responses for edge cases
Ready for Phase 3: ApiVersions matrix accuracy
Core SeaweedMQ Integration completed:
## Implementation
- Implement SeaweedMQHandler.GetStoredRecords() to retrieve actual records from SeaweedMQ
- Add SeaweedSMQRecord wrapper implementing offset.SMQRecord interface
- Wire Fetch API to use real SMQ records instead of synthetic batches
- Support both agent and broker client connections for record retrieval
## Key Features
- Proper Kafka offset mapping from SeaweedMQ records
- Respects maxRecords limit and batch size constraints
- Graceful error handling for missing topics/partitions
- High water mark boundary checking
## Tests
- Unit tests for SMQRecord interface compliance
- Edge case testing (empty topics, offset boundaries, limits)
- Integration with existing end-to-end Kafka tests
- Benchmark tests for record accessor performance
## Verification
- All integration tests pass
- E2E Sarama test shows 'Found X SMQ records' debug output
- GetStoredRecords now returns real data instead of TODO placeholder
Ready for Phase 2: CreateTopics protocol compliance
- Fix gateway tests: Replace AgentAddress with Masters in Options struct
- Fix consumer test: Correct GenerateMemberID test to expect deterministic behavior
- Fix schema tests: Remove incorrect error assertions for mock broker scenarios
- All core offset management and protocol tests now pass
- Gateway, consumer, protocol, and offset packages compile and test successfully
- Remove old SMQIntegratedStorage implementation from persistence.go
- Update all integration modules to use SMQOffsetStorage instead
- Add delegation methods to PersistentLedger for backward compatibility
- Fix method signatures and compilation errors
- Maintain support for legacy offset operations through SeaweedMQStorage
- Add end-to-end flow tests for Kafka OffsetCommit to SMQ storage
- Test multiple consumer groups with independent offset tracking
- Validate SMQ file path and format compatibility
- Test error handling and edge cases (negative, zero, max offsets)
- Verify offset encoding/decoding matches SMQ broker format
- Ensure consumer group isolation and proper key generation
- Update Kafka protocol handler to use SMQOffsetStorage for consumer offsets
- Modify OffsetCommit to save consumer offsets using SMQ's filer format
- Modify OffsetFetch to read consumer offsets from SMQ's filer location
- Add proper ConsumerOffsetKey creation with consumer group and instance ID
- Maintain backward compatibility with in-memory storage fallback
- Include comprehensive test coverage for offset handler integration
- Add SMQOffsetStorage that uses same filer locations and format as SMQ brokers
- Store offsets in <topic-dir>/<partition-dir>/<consumerGroup>.offset files
- Use 8-byte big-endian format matching SMQ broker implementation
- Include comprehensive test coverage for core functionality
- Maintain backward compatibility through legacy method support
🎉 HISTORIC ACHIEVEMENT: 100% Consumer Group Protocol Working!
✅ Complete Protocol Implementation:
- FindCoordinator v2: Fixed response format with throttle_time, error_code, error_message
- JoinGroup v5: Fixed request parsing with client_id and GroupInstanceID fields
- SyncGroup v3: Fixed request parsing with client_id and response format with throttle_time
- OffsetFetch: Fixed complete parsing with client_id field and 1-byte offset correction
🔧 Technical Fixes:
- OffsetFetch uses 1-byte array counts instead of 4-byte (compact arrays)
- OffsetFetch topic name length uses 1-byte instead of 2-byte
- Fixed 1-byte off-by-one error in offset calculation
- All protocol version compatibility issues resolved
🚀 Consumer Group Functionality:
- Full consumer group coordination working end-to-end
- Partition assignment and consumer rebalancing functional
- Protocol compatibility with Sarama and other Kafka clients
- Consumer group state management and member coordination complete
This represents a MAJOR MILESTONE in Kafka protocol compatibility for SeaweedFS
- Created consumer group tests for basic functionality, offset management, and rebalancing
- Added debug test to isolate consumer group coordination issues
- Root cause identified: Sarama repeatedly calls FindCoordinator but never progresses to JoinGroup
- Issue: Connections closed after FindCoordinator, preventing coordinator protocol
- Consumer group implementation exists but not being reached by Sarama clients
Next: Fix coordinator connection handling to enable JoinGroup protocol
🎉 MAJOR SUCCESS: Both kafka-go and Sarama now fully working!
Root Cause:
- Individual message batches (from Sarama) had base offset 0 in binary data
- When Sarama requested offset 1, it received batch claiming offset 0
- Sarama ignored it as duplicate, never got actual message 1,2
Solution:
- Correct base offset in record batch header during StoreRecordBatch
- Update first 8 bytes (base_offset field) to match assigned offset
- Each batch now has correct internal offset matching storage key
Results:
✅ kafka-go: 3/3 produced, 3/3 consumed
✅ Sarama: 3/3 produced, 3/3 consumed
Both clients now have full produce-consume compatibility
chrislu