spacedriveapp/spacedrive · error · anyhow::Error

Unexpected response type: {}

Error message

Unexpected response type: {}

What it means

Reading the final acknowledgment expects a framing byte of 0 (the marker for rmp-serialized messages) followed by a length, but the first byte read was non-zero. The bytes on the receive stream do not follow the expected framing - typically version skew between the two daemons, or a misaligned or corrupted stream. The offending byte value is included in the error.

Source

Thrown at core/src/ops/files/copy/strategy.rs:1286

		.await?;
	send_stream.write_all(&completion_data).await?;
	send_stream.flush().await?;

	ctx.log(format!(
		"Completion message sent, waiting for final acknowledgment from receiver"
	));

	send_stream
		.finish()
		.map_err(|e| anyhow::anyhow!("Failed to finish stream: {}", e))?;

	ctx.log("Waiting for TransferFinalAck from receiver...".to_string());

	let mut msg_type = [0u8; 1];
	recv_stream.read_exact(&mut msg_type).await?;

	if msg_type[0] != 0 {
		return Err(anyhow::anyhow!("Unexpected response type: {}", msg_type[0]));
	}

	let mut len_buf = [0u8; 4];
	recv_stream.read_exact(&mut len_buf).await?;
	let msg_len = u32::from_be_bytes(len_buf) as usize;

	let mut msg_buf = vec![0u8; msg_len];
	recv_stream.read_exact(&mut msg_buf).await?;

	let ack_message: crate::service::network::protocol::file_transfer::FileTransferMessage =
		rmp_serde::from_slice(&msg_buf)?;

	match ack_message {
		crate::service::network::protocol::file_transfer::FileTransferMessage::TransferFinalAck { transfer_id: ack_id } => {
			if ack_id != transfer_id {
				return Err(anyhow::anyhow!("Received ack for wrong transfer: expected {}, got {}", transfer_id, ack_id));
			}
			ctx.log("Received TransferFinalAck from receiver - transfer confirmed!".to_string());

View on GitHub (pinned to 6dfeccf211)

Solutions

1. Confirm both devices run the same sd-core version and upgrade the outlier
2. Retry once on a fresh connection to rule out stream misalignment
3. Note the reported byte value - a consistent non-zero value identifies the peer's frame type and confirms version skew
4. Re-pair devices after upgrading if the errors persist

match recv_stream.read_exact(&mut msg_type).await {
    Ok(_) if msg_type[0] == 0 => { /* expected framing */ }
    Ok(_) => {
        // Protocol mismatch: do not retry on this connection; require matching versions.
        anyhow::bail!("Protocol framing mismatch (byte {}) - align device versions", msg_type[0]);
    }
    Err(e) => return Err(e.into()),
}

When it happens

Trigger: Peer running a different protocol version whose framing differs; the receive stream left misaligned by an earlier partial read; peer sent an unrecognized frame type.

Common situations: One device upgraded sd-core while the other stayed on an old version; mixed-version LANs; downgrade and upgrade cycles leaving incompatible peers paired.

Related errors

• Transfer error: {}
• Transfer interrupted: received {} of {} bytes before connect
• Failed to open stream: {}
• Failed to write message length: {}
• Failed to write chunk data: {}

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