GitoxideLabs/gitoxide · error

BUG: no other error type is possible

Error message

BUG: no other error type is possible

What it means

During a fast multi-index integrity verification, the per-index traversal is expected to fail only with `index::traverse::Error::Processor` (the caller-supplied processor error). Any other traversal error variant is treated as an unreachable bug and panics rather than being propagated.

Solutions

  1. Check the pack/idx files with `git verify-pack` or gix bundle verify to find and repair corruption
  2. Re-clone or re-generate the affected pack/multi-index files
  3. Upgrade gix-pack so all traverse error variants are mapped instead of panicking, and report the panic upstream

Example fix

// before
_ => unreachable!("BUG: no other error type is possible"),
// after
err => return Err(Error::Verify(err.to_string())),
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-verify each idx/pack before the combined fast verify
for path in &index_paths { gix_pack::index::File::at(path, ...)?.verify_integrity(...)?; }

Type guard

fn is_processor_err(err: &index::traverse::Error) -> bool {
    matches!(err, index::traverse::Error::Processor(_))
}

Try / catch

match bundle.verify_integrity_fast(progress, should_interrupt) {
    Ok(checksum) => checksum,
    Err(e) => { log::error!("multi-index verification failed: {e}"); return Err(e); }
}

Prevention

When it happens

Trigger: Calling `Bundle::verify_integrity_fast` (or the multi-index equivalent) when the underlying index traversal fails with a non-Processor error — e.g. pack decode/corruption errors from `index::traverse` that are not routed through the processor variant.

Common situations: Verifying a multi-index whose pack or idx files are corrupted or truncated; interrupted traversals surfacing unexpected variants; version skew where traverse::Error gained new variants the multi-index code does not map.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of GitoxideLabs/gitoxide@e73179060b (2026-09-08). Data as JSON: /api/errors/3bcf25acedf74e3d. Report an issue: GitHub.

Appendix: source

Thrown at gix-pack/src/multi_index/verify.rs:115

    }

    /// Similar to [`verify_integrity()`][File::verify_integrity()] but without any deep inspection of objects.
    ///
    /// Instead we only validate the contents of the multi-index itself.
    pub fn verify_integrity_fast(
        &self,
        progress: &mut dyn DynNestedProgress,
        should_interrupt: &AtomicBool,
    ) -> Result<gix_hash::ObjectId, integrity::Error> {
        self.verify_integrity_inner(
            progress,
            should_interrupt,
            false,
            index::verify::integrity::Options::default(),
        )
        .map_err(|err| match err {
            index::traverse::Error::Processor(err) => err,
            _ => unreachable!("BUG: no other error type is possible"),
        })
        .map(|o| o.actual_index_checksum)
    }

    /// Similar to [`crate::Bundle::verify_integrity()`] but checks all contained indices and their packs.
    ///
    /// Note that it's considered a failure if an index doesn't have a corresponding pack.
    pub fn verify_integrity<C, F>(
        &self,
        progress: &mut dyn DynNestedProgress,
        should_interrupt: &AtomicBool,
        options: index::verify::integrity::Options<F>,
    ) -> Result<integrity::Outcome, index::traverse::Error<integrity::Error>>
    where
        C: crate::cache::DecodeEntry,
        F: Fn() -> C + Send + Clone,
    {
        self.verify_integrity_inner(progress, should_interrupt, true, options)

View on GitHub (pinned to e73179060b)