NoopDownloader cannot fetch media info; this item is driven…

Error message

NoopDownloader cannot fetch media info; this item is driven by an external plugin

What it means

`NoopDownloader` is a placeholder implementation of the platform trait: `can_handle` always returns false and `get_media_info` is a hard error. Items routed to it are expected to be driven entirely by an external plugin, so the built-in media-info path must never be invoked on them; calling it anyway surfaces this error.

Solutions

Check `can_handle(url)` (or the item's plugin ownership flag) before calling `get_media_info`; route plugin-owned items to the external plugin driver instead
Verify the external plugin for this platform is installed and registered so items don't fall back to NoopDownloader
Fix the downloader-selection/dispatch logic that assigned NoopDownloader to a URL that should have matched a real platform
In tests, use a stub downloader rather than NoopDownloader when exercising media-info flows

Example fix

// before
let info = downloader.get_media_info(&url).await?;
// after
if downloader.is_noop() {
    anyhow::bail!("item {} is plugin-driven; use plugin.get_media_info", item_id);
}
let info = downloader.get_media_info(&url).await?;

Defensive patterns

Strategy: type-guard

Validate before calling

fn uses_builtin_media_info(d: &dyn PlatformDownloader, url: &str) -> bool {
    d.can_handle(url) && !d.is_noop()
}

Type guard

fn is_noop(d: &dyn PlatformDownloader) -> bool {
    // NoopDownloader::can_handle always returns false; treat non-handling backends as plugin-driven
    !d.can_handle("")
}

// before calling:
// if is_noop(&downloader) { route_to_plugin(&item)?; }

Try / catch

match downloader.get_media_info(&url).await {
    Err(e) if e.to_string().contains("NoopDownloader cannot fetch media info") => {
        plugin_executor::get_media_info(&item).await.context("item is plugin-driven")
    }
    other => other,
}

Prevention

Check can_handle(url) before invoking get_media_info; never call built-ins on plugin-owned items
Ensure external plugins are installed and registered so items don't fall back to NoopDownloader
Mark items with their owning backend and branch on it in the scheduler
Add a dispatcher test asserting no plugin-owned item reaches NoopDownloader built-ins

When it happens

Trigger: Calling `get_media_info` on a `NoopDownloader` instance — i.e. a download item whose platform resolved to the noop backend (external plugin ownership) but was sent through the normal built-in media-info pipeline instead of the plugin path.

Common situations: Dispatcher/routing bug that maps unknown or plugin-owned URLs to NoopDownloader and then calls the standard flow; external plugin not installed/loaded so the item fell back to noop; tests accidentally exercising the noop backend.

Related errors

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

Appendix: source

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

impl Default for NoopDownloader {
    fn default() -> Self {
        Self::new()
    }
}

#[async_trait]
impl PlatformDownloader for NoopDownloader {
    fn name(&self) -> &str {
        "external"
    }

    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)