spacedriveapp/spacedrive · error · anyhow::Error
Failed to read response length: {}
Error message
Failed to read response length: {} What it means
recv.read_exact for the 4-byte response length failed in send_sync_request. read_exact returns UnexpectedEof when the peer closes the stream without responding, and a connection error when the link drops - in both cases the peer never answered the request.
Source
Thrown at core/src/service/network/protocol/sync/transport.rs:184
let len = req_bytes.len() as u32;
send.write_all(&len.to_be_bytes())
.await
.map_err(|e| anyhow::anyhow!("Failed to send length: {}", e))?;
send.write_all(&req_bytes)
.await
.map_err(|e| anyhow::anyhow!("Failed to send request: {}", e))?;
// Properly close send stream
send.finish()
.map_err(|e| anyhow::anyhow!("Failed to finish stream: {}", e))?;
debug!("Sync request sent, waiting for response...");
// Read response with timeout
let result = timeout(Duration::from_secs(60), async {
let mut len_buf = [0u8; 4];
recv.read_exact(&mut len_buf).await.map_err(|e| {
anyhow::anyhow!("Failed to read response length: {}", e)
})?;
let resp_len = u32::from_be_bytes(len_buf) as usize;
debug!("Receiving sync response of {} bytes", resp_len);
let mut resp_buf = vec![0u8; resp_len];
recv.read_exact(&mut resp_buf)
.await
.map_err(|e| anyhow::anyhow!("Failed to read response: {}", e))?;
Ok::<_, anyhow::Error>(resp_buf)
})
.await;
let resp_buf = match result {
Ok(Ok(buf)) => buf,
Ok(Err(e)) => return Err(e),
Err(_) => {
return Err(anyhow::anyhow!(View on GitHub (pinned to 6dfeccf211)
Solutions
- Check peer logs: did its sync handler receive and process the request?
- Verify both sides use the same length-prefixed bidirectional framing
- Retry once on a new connection
- Confirm protocol version compatibility between the two devices
Defensive patterns
Strategy: retry
Try / catch
Err(e) if e.to_string().contains("Failed to read response length") => {
// peer never answered: verify peer handler ran, then retry once on a new connection
check_peer_logs(device);
retry_request_on_fresh_connection(device, request).await
} Prevention
- Keep peers on compatible versions so handlers always respond
- Retry once on a fresh connection before marking the peer broken
- Log which request type produced the silent peer so peers can be debugged
When it happens
Trigger: Peer accepted the request but crashed or closed before responding; peer does not implement the length-prefixed response framing; connection lost while awaiting the response.
Common situations: Peer daemon crash mid-handler; version skew where the peer silently drops the request; peer killed by the OS under memory pressure.
Related errors
- Failed to read response: {}
- Failed to open bidirectional stream: {}
- Failed to send length: {}
- Failed to send request: {}
- Failed to open stream: {}
AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16).
Data as JSON: /api/errors/6c68b9d24817ebab.
Report an issue: GitHub.