Files
seaweedfs/weed
chrislu 8ef2cb5b16 fix: Use actual broker nodeID in partition metadata for Metadata responses
## 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
2025-10-16 18:37:37 -07:00
..
2025-10-13 18:05:17 -07:00
2025-10-14 13:04:33 -07:00
2025-10-13 18:05:17 -07:00
2025-10-13 18:05:17 -07:00
2025-10-15 22:56:47 -07:00
2025-10-13 18:05:17 -07:00
2025-08-31 23:31:28 -07:00
2025-08-22 01:15:42 -07:00
2025-10-15 16:08:21 -07:00
2025-10-13 18:05:17 -07:00
2024-06-25 09:18:11 -07:00
2025-10-13 18:05:17 -07:00
2025-08-30 11:15:48 -07:00
2025-10-13 18:05:17 -07:00
2024-02-14 08:26:38 -08:00
2025-10-13 18:05:17 -07:00
2025-10-13 18:05:17 -07:00
2025-10-13 18:05:17 -07:00
2025-10-13 18:05:17 -07:00
2025-07-19 21:43:34 -07:00
2025-03-17 23:13:27 -07:00