t8y2/dbx · error

root count checked above

Error message

root count checked above

What it means

While extracting an uploaded JRE archive, the code collects the top-level directory entries and requires exactly one root directory ("Invalid JRE archive: expected a single top-level directory" otherwise). It then takes roots.pop().expect("root count checked above") — a guard-protected extraction that panics only if the len()!=1 check no longer precedes the pop (e.g. refactoring, or the Vec was mutated between check and use).

Source

Thrown at crates/dbx-core/src/agent_service.rs:3162

fn extract_jre_tar<R: Read>(mut archive: tar::Archive<R>, dest: &Path) -> Result<(), String> {
    let parent = dest.parent().ok_or_else(|| format!("Invalid JRE destination: {}", dest.display()))?;
    std::fs::create_dir_all(parent).map_err(|e| format!("Failed to create JRE directory: {e}"))?;

    let staging = tempfile::Builder::new()
        .prefix(".jre-extract-")
        .tempdir_in(parent)
        .map_err(|e| format!("Failed to create JRE extraction directory: {e}"))?;
    archive.unpack(staging.path()).map_err(|e| format!("Failed to extract JRE archive: {e}"))?;

    let mut roots = std::fs::read_dir(staging.path())
        .map_err(|e| format!("Failed to inspect extracted JRE archive: {e}"))?
        .collect::<Result<Vec<_>, _>>()
        .map_err(|e| format!("Failed to inspect extracted JRE archive: {e}"))?;
    if roots.len() != 1 {
        return Err("Invalid JRE archive: expected a single top-level directory".to_string());
    }

    let root = roots.pop().expect("root count checked above");
    if !root.file_type().map_err(|e| format!("Failed to inspect extracted JRE archive: {e}"))?.is_dir() {
        return Err("Invalid JRE archive: expected a top-level directory".to_string());
    }

    std::fs::create_dir_all(dest).map_err(|e| format!("Failed to create JRE directory: {e}"))?;
    for entry in std::fs::read_dir(root.path()).map_err(|e| format!("Failed to inspect extracted JRE archive: {e}"))? {
        let entry = entry.map_err(|e| format!("Failed to inspect extracted JRE archive: {e}"))?;
        std::fs::rename(entry.path(), dest.join(entry.file_name()))
            .map_err(|e| format!("Failed to install extracted JRE: {e}"))?;
    }
    Ok(())
}

#[cfg(test)]
mod jre_archive_tests {
    use super::*;
    use std::io::Cursor;

View on GitHub (pinned to c0390bff16)

Solutions

  1. Repackage the JRE so it contains exactly one top-level directory (e.g. tar -czf jre.tar.gz jre/).
  2. Keep the len()!=1 guard immediately before roots.pop(); never mutate `roots` between check and pop.
  3. Replace expect with `let Some(root) = roots.pop() else { return Err(...) }` to make the invariant self-enforcing.
  4. Validate archive layout (single root dir) client-side before upload to fail fast with a clear message.

Example fix

// before
let root = roots.pop().expect("root count checked above");
// after
let Some(root) = roots.pop() else {
    return Err("Invalid JRE archive: expected a single top-level directory".to_string());
};
Defensive patterns

Strategy: validation

Validate before calling

// validate the JRE archive layout before extraction (client side)
let names: Vec<String> = list_archive_top_level(archive)?;
if names.len() != 1 {
    return Err(format!("JRE archive must have a single top-level directory, found {}", names.len()));
}

Type guard

fn single_root<'a>(entries: &'a [ArchiveEntry]) -> Option<&'a ArchiveEntry> {
    if entries.len() == 1 { entries.first() } else { None }
}

Try / catch

let Some(root) = roots.pop() else {
    return Err("Invalid JRE archive: expected a single top-level directory".to_string());
};

Prevention

When it happens

Trigger: Directly unreachable while the `if roots.len() != 1 { return Err(...) }` guard precedes roots.pop(). The underlying user-facing failure occurs when a JRE .tar.gz/.zip has zero or multiple top-level entries, which returns the Err, not the panic. The USED AT lines in agents/drivers (kingbase-go DSN tests, neo4j-go cert pool) are unrelated call sites surfaced by search, not part of this code path.

Common situations: Users upload JRE archives that were zipped from multiple folders or with files at the archive root instead of a single enclosing directory (common with macOS Finder 'compress' or selecting several items); extraction code refactors that drop the guard produce panics instead of the friendly Err.

Related errors


AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/3eae08f385780ca9. Report an issue: GitHub.