mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-10-12 01:07:35 +02:00
chrislu
8ef2cb5b16
## Problem Metadata responses were hardcoding partition leader and replica nodeIDs to 1, but the actual broker's nodeID is different (0x4fd297f2 / 1329658354). This caused Java clients to get confused: 1. Client reads: "Broker is at nodeID=0x4fd297f2" 2. Client reads: "Partition leader is nodeID=1" 3. Client looks for broker with nodeID=1 → not found 4. Client can't determine leader → retries Metadata request 5. Same wrong response → infinite retry loop until timeout ## Solution Use the actual broker's nodeID consistently: - LeaderID: nodeID (was int32(1)) - ReplicaNodes: [nodeID] (was [1]) - IsrNodes: [nodeID] (was [1]) Now the response is consistent: - Broker: nodeID = 0x4fd297f2 - Partition leader: nodeID = 0x4fd297f2 - Replicas: [0x4fd297f2] - ISR: [0x4fd297f2] ## Impact With both fixes (hostname + nodeID): - Schema Registry consumer won't get stuck - Consumer can proceed to JoinGroup/SyncGroup/Fetch - Producer can send Noop record - Schema Registry initialization completes successfully