NoopDownloader cannot drive download; this item is driven…

Error message

NoopDownloader cannot drive download; this item is driven by an external plugin

What it means

Same placeholder contract as error 1118 but for the download step: `NoopDownloader::download` always errors because actual downloading for these items is delegated to an external plugin. Hitting this error means the built-in download pipeline was invoked on a plugin-owned item that the noop backend must not drive.

Solutions

Route plugin-owned items to the external plugin's download executor; never enqueue NoopDownloader items into the built-in pipeline
Ensure the responsible external plugin is installed, loaded, and healthy before starting the item's download
Persist plugin-ownership metadata with each queue item so restarts don't misroute it to the noop backend
Surface a distinct 'requires external plugin' state in the UI rather than attempting the built-in download

Example fix

// before
let result = downloader.download(&info, &opts, progress_tx).await?;
// after
if downloader.is_noop() {
    return plugin_executor::download(&item, &opts, progress_tx).await
        .context("item requires external plugin driver");
}
let result = downloader.download(&info, &opts, progress_tx).await?;

Defensive patterns

Strategy: type-guard

Validate before calling

fn ensure_builtin_download(d: &dyn PlatformDownloader) -> Result<(), String> {
    if d.is_noop() { Err("item requires external plugin driver".into()) } else { Ok(()) }
}

Type guard

fn can_builtin_download(d: &dyn PlatformDownloader) -> bool {
    !d.is_noop()
}

Try / catch

match downloader.download(&info, &opts, tx).await {
    Err(e) if e.to_string().contains("NoopDownloader cannot drive download") => {
        plugin_executor::download(&item, &opts, tx).await.context("requires external plugin")
    }
    other => other,
}

Prevention

Persist plugin-ownership metadata per queue item so restarts don't misroute to the noop backend
Gate the built-in download loop on the item's backend type; send noop items to the plugin executor
Alert when a plugin fails to load and block its items instead of silently falling back to NoopDownloader
Cover the dispatch path with tests that simulate a missing plugin

When it happens

Trigger: Calling `download(info, opts, progress_tx)` on a `NoopDownloader` — a plugin-owned or unrecognized-platform item dispatched through the built-in download loop instead of the external plugin executor.

Common situations: External plugin missing or failed to load, so the scheduler still enqueued the item into the built-in pipeline; dispatcher bug assigning NoopDownloader to resumable/legacy items; queue replay after restart where plugin ownership metadata was lost.

Related errors

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

Appendix: source

Thrown at src-tauri/src/platforms/noop.rs:42

    }

    fn can_handle(&self, _url: &str) -> bool {
        false
    }

    async fn get_media_info(&self, _url: &str) -> anyhow::Result<MediaInfo> {
        Err(anyhow::anyhow!(
            "NoopDownloader cannot fetch media info; this item is driven by an external plugin"
        ))
    }

    async fn download(
        &self,
        _info: &MediaInfo,
        _opts: &DownloadOptions,
        _progress: tokio::sync::mpsc::Sender<omniget_core::models::progress::ProgressUpdate>,
    ) -> anyhow::Result<DownloadResult> {
        Err(anyhow::anyhow!(
            "NoopDownloader cannot drive download; this item is driven by an external plugin"
        ))
    }
}

View on GitHub (pinned to 8600b91f42)