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

  1. Check peer logs: did its sync handler receive and process the request?
  2. Verify both sides use the same length-prefixed bidirectional framing
  3. Retry once on a new connection
  4. 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

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


AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16). Data as JSON: /api/errors/6c68b9d24817ebab. Report an issue: GitHub.