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
- Repackage the JRE so it contains exactly one top-level directory (e.g. tar -czf jre.tar.gz jre/).
- Keep the len()!=1 guard immediately before roots.pop(); never mutate `roots` between check and pop.
- Replace expect with `let Some(root) = roots.pop() else { return Err(...) }` to make the invariant self-enforcing.
- 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
- Repackage JRE archives so all contents live under one top-level directory.
- Validate archive structure before upload/extraction.
- Never mutate the entries Vec between the length check and pop.
- Add tests for archives with 0 and 2+ root entries.
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
- a batch cancellation token is always available
- driver token registered
- JRE install lock table poisoned
- a cancellation token is always available
- checked one driver
AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05).
Data as JSON: /api/errors/3eae08f385780ca9.
Report an issue: GitHub.