feat: implement cluster health monitoring and chunk replication by murka · Pull Request #1 · monoce/gateway

6 issues identified (18 code objects reviewed).

• Merge Base: 0b785f0
• Head: 1fa1c61

src/bin/gateway.rs

line 32: The spawned background tasks discard their JoinHandles, meaning if health_check_loop or replication_loop panics, the task will silently die and never restart. The gateway would continue running while believing background health checks and replication are working, but they would have stopped entirely. [ Low confidence ]
line 34: Both background loops call tokio::time::sleep() before the first execution of health_check_loop and replication_loop. This means the initial health check won't run until 2 seconds after startup, and initial replication won't run until 10 seconds after startup. If immediate execution on startup is expected, this ordering is incorrect. [ Low confidence ]

src/cluster.rs

line 99: In replication_loop, after dropping the read locks at lines 86-87, the state can change before the write lock is acquired at line 99. Another concurrent operation could remove the chunk from chunk_locations or change the replica set, making the update at lines 100-104 operate on stale assumptions. The chunk_cid might no longer exist when locations.get_mut(&chunk_cid) is called. [ Low confidence ]
line 99: In replication_loop, a new write lock is acquired and released for each replication task in the loop (line 99). If many chunks need replication, this results in repeated lock acquisition overhead and potential contention. Consider batching the updates. [ Low confidence ]

src/handlers.rs

line 90: The chunk_locations field is initialized as an empty HashMap and only read in get_chunk_locations(), but there is no visible code that populates this map when chunks are actually stored on remote nodes. This means get_chunk_locations() will only ever return locally stored chunks, never returning the locations of chunks distributed to other storage nodes via create_session(). [ Low confidence ]
line 101: If address is provided without a URL scheme (e.g., example.com:8080 instead of http://example.com:8080), the reqwest client will fail to send the request, causing all health checks to return false for such nodes. The function silently treats this as an unhealthy node rather than a configuration error. [ Low confidence ]
line 101: URL construction in format!("{}/health", address) doesn't handle the case where address already ends with a trailing slash, resulting in a malformed URL like http://example.com//health. This could cause the health check to fail or route incorrectly depending on the server configuration. [ Low confidence ]