What causes "Download cancelled" in tonhowtf/omniget?

Treat this as expected control flow: catch it and show a cancelled state rather than an error.

Download cancelled

Error message

Download cancelled

What it means

Inside the variant loop, if a CancellationToken supplied by the caller has been cancelled, the function aborts immediately with "Download cancelled" instead of continuing to other resolution variants or completing the download.

Solutions

Treat this as expected control flow: catch it and show a cancelled state rather than an error.
Ensure a fresh CancellationToken is created per download instead of reusing one from a previously cancelled job.
Only cancel the token from the UI after confirming the user intends to abort.
Persist partial output cleanup on cancellation so no corrupt files remain.

Example fix

// before
if let Some(token) = cancel {
    if token.is_cancelled() {
        return Err(anyhow!("Download cancelled"));
    }
}
// after: caller-side handling as control flow, not failure
match downloader.download_video_with_fallback(url, out, tx, Some(&token)).await {
    Err(e) if e.to_string() == "Download cancelled" => { /* show 'cancelled', not error */ }
    other => other?,
}

Defensive patterns

Strategy: try-catch

Validate before calling

// check token state before starting a new job
if cancel_token.map(|t| t.is_cancelled()).unwrap_or(false) {
    return; // do not start a download with a cancelled token
}

Try / catch

match download(...).await {
    Err(e) if e.to_string() == "Download cancelled" => {
        ui.set_state(JobState::Cancelled);
        cleanup_partial_output(output);
    }
    Err(e) => ui.set_state(JobState::Failed(e.to_string())),
    Ok(bytes) => ui.set_state(JobState::Done(bytes)),
}

Prevention

Create a fresh CancellationToken per download job; never reuse cancelled ones.
Treat cancellation as normal control flow, not a failure state.
Clean up partial files when a download is cancelled.
Cancel tokens only from explicit user actions.

When it happens

Trigger: User cancels the download in the UI (or the app shuts down) while download_video_with_fallback is iterating resolution variants, and token.is_cancelled() returns true at a loop iteration boundary.

Common situations: User taps cancel mid-download, app window closes during a long download, or a stale/reused cancellation token is passed in when starting a new download.

Related errors

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

Appendix: source

Thrown at src-tauri/omniget-core/src/platforms/reddit.rs:218

            }
        }
        variants
    }

    async fn download_video_with_fallback(
        &self,
        video_url: &str,
        output: &std::path::Path,
        progress_tx: mpsc::Sender<ProgressUpdate>,
        cancel: Option<&tokio_util::sync::CancellationToken>,
    ) -> anyhow::Result<u64> {
        let variants = Self::get_resolution_variants(video_url);
        let mut last_err = anyhow!("No resolution available");

        for variant in &variants {
            if let Some(token) = cancel {
                if token.is_cancelled() {
                    return Err(anyhow!("Download cancelled"));
                }
            }
            match direct_downloader::download_direct(
                &self.client,
                variant,
                output,
                progress_tx.clone(),
                cancel,
            )
            .await
            {
                Ok(bytes) => return Ok(bytes),
                Err(e) => {
                    last_err = e;
                    let _ = tokio::fs::remove_file(output).await;
                }
            }
        }

View on GitHub (pinned to 8600b91f42)