tonhowtf/omniget · warning

Receiver rejected transfer

Error message

Receiver rejected transfer: {}

What it means

After the header, the receiver must reply exactly "OK" to accept the transfer. Any other line (including relay error text that check_relay_error wasn't called on here, "NO", or garbage) makes run_sender bail with "Receiver rejected transfer: {response}".

Solutions

1. Read the echoed response in the message — it names why the receiver refused; show it to the user.
2. On the receiver side, ensure acceptance always writes exactly the line "OK\n".
3. Check the receiver's disk space and write permissions for its download directory.
4. Align client versions so the accept/reject tokens match, and consider running check_relay_error on ok_response to separate relay faults from real rejections.

Example fix

// before
if ok_response != "OK" { anyhow::bail!("Receiver rejected transfer: {}", ok_response); }
// after
check_relay_error(&ok_response)?; // distinguish relay errors from real rejection
if ok_response != "OK" {
    anyhow::bail!("Receiver rejected transfer: {:?}", ok_response);
}

// receiver-side self-check before accepting
tokio::fs::write(&out_dir, b"x").await?; // ensures disk writable and space available

match run_sender(session.clone(), cancel.clone()).await {
    Err(e) if e.to_string().contains("Receiver rejected transfer") => {
        let reason = extract_after(&e.to_string(), "transfer: ");
        ui.show_rejection_reason(reason);
    }
    other => other?,
}

When it happens

Trigger: Receiver answers the header with a token other than "OK" — explicit rejection, receiver-side disk/permission error serialized as a message, or a relay error line forwarded verbatim.

Common situations: Receiver declines the prompt, receiver lacks write permission or disk space and its client replies with an error token, or client version mismatch causes the accept token to differ.

Related errors

• Receiver rejected transfer
• Relay error
• Unexpected relay response
• Relay error
• Invalid file size from sender

AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12). Data as JSON: /api/errors/bd574a8afdf186b7. Report an issue: GitHub.

Appendix: source

Thrown at src-tauri/src/platforms/p2p/mod.rs:299

        anyhow::bail!("Unexpected relay response: {}", ready);
    }

    *session.status.lock().await = "connected".to_string();
    tracing::info!("[p2p] receiver connected");

    let header = format!("{}\n{}\n", session.file_name, session.file_size);
    write_half.write_all(header.as_bytes()).await?;
    write_half.flush().await?;

    let ok_response = tokio::select! {
        line = read_line(&mut reader) => line?,
        _ = cancel.cancelled() => {
            anyhow::bail!("Send cancelled while waiting for OK");
        }
    };

    if ok_response != "OK" {
        anyhow::bail!("Receiver rejected transfer: {}", ok_response);
    }

    *session.status.lock().await = "transferring".to_string();
    tracing::info!(
        "[p2p] transferring: {} ({} bytes)",
        session.file_name,
        session.file_size
    );

    let mut file = File::open(&session.file_path).await?;
    let mut buf = vec![0u8; CHUNK_SIZE];
    let mut sent: u64 = 0;

    loop {
        if cancel.is_cancelled() {
            anyhow::bail!("Send cancelled during transfer");
        }

View on GitHub (pinned to 8600b91f42)