tonhowtf/omniget · error · anyhow::Error

could not determine app data dir

Error message

could not determine app data dir

What it means

ensure_pdfium_with_variant() resolves the directory where the pdfium native library will be installed via pdfium_target_dir(). If that resolver returns None (app data dir unavailable, e.g. called outside the Tauri context or the platform provides no data dir), installation cannot proceed and this error is thrown before any download happens.

Solutions

  1. Call ensure_pdfium after the app data directory is initialized and resolvable
  2. Verify platform data-dir environment (HOME, XDG_DATA_HOME, APPDATA) is set
  3. Inspect pdfium_target_dir() and add a fallback path or clearer diagnostic
  4. For headless/CI use, pre-install pdfium manually via set_pdfium_from_path

Example fix

// before
let target_dir = pdfium_target_dir().ok_or_else(|| anyhow!("could not determine app data dir"))?;
// after
let target_dir = pdfium_target_dir()
    .or_else(|| dirs::data_dir().map(|d| d.join("pdfium")))
    .ok_or_else(|| anyhow!("could not determine app data dir"))?;
Defensive patterns

Strategy: validation

Validate before calling

fn pdfium_installable() -> bool {
    std::env::var("HOME").is_ok()
        || std::env::var("APPDATA").is_ok()
        || std::env::var("XDG_DATA_HOME").is_ok()
}

Try / catch

match ensure_pdfium().await {
    Err(e) if e.to_string().contains("app data dir") => {
        // fall back to a system-wide or bundled pdfium
    }
    other => other.map(|_| ()),
}

Prevention

When it happens

Trigger: Calling ensure_pdfium() or ensure_pdfium_with_variant() when pdfium_target_dir() returns None — typically before Tauri app setup completes, in tests, or on systems where the OS data-dir lookup fails.

Common situations: First-run pdfium download on a machine with a misconfigured XDG_DATA_HOME/HOME; invoking installer logic from a headless test; running on an unsupported platform where the data dir API returns None.

Understand the failure class

Background: "missing required config value" errors: why libraries refuse to start when a configuration key is empty, unset, or blank — this error's family across 48 libraries.

Related errors


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

Appendix: source

Thrown at src-tauri/omniget-core/src/core/pdfium.rs:163

pub fn read_version_marker() -> Option<String> {
    let p = pdfium_version_marker_path()?;
    let s = std::fs::read_to_string(&p).ok()?;
    let trimmed = s.trim().to_string();
    if trimmed.is_empty() {
        None
    } else {
        Some(trimmed)
    }
}

pub async fn ensure_pdfium() -> anyhow::Result<PathBuf> {
    ensure_pdfium_with_variant(None).await
}

pub async fn ensure_pdfium_with_variant(variant: Option<String>) -> anyhow::Result<PathBuf> {
    let target_dir =
        pdfium_target_dir().ok_or_else(|| anyhow!("could not determine app data dir"))?;
    std::fs::create_dir_all(&target_dir)
        .with_context(|| format!("creating pdfium target dir {}", target_dir.display()))?;

    let archive_name = archive_name_for_variant(variant.as_deref());
    let url = format!("{}/{}", PDFIUM_DOWNLOAD_BASE, archive_name);
    let lib_filename = pdfium_lib_filename();
    let target_path = target_dir.join(lib_filename);

    tracing::info!("Downloading pdfium from {}", url);

    let client = crate::core::http_client::apply_global_proxy(reqwest::Client::builder())
        .timeout(std::time::Duration::from_secs(600))
        .build()?;

    let response = client.get(&url).send().await?;
    if !response.status().is_success() {
        return Err(anyhow!(
            "Failed to download pdfium from {}: HTTP {}",

View on GitHub (pinned to 8600b91f42)