GitoxideLabs/gitoxide · error

Should never see other errors than zlib, but got

Error message

Should never see other errors than zlib, but got {:?}

What it means

This is a Rust `unreachable!()` panic in `compress_data` (gix-pack). When deflating an object with zlib, the code maps `std::io::ErrorKind::Other` to a normal I/O error, and treats any other io::ErrorKind as impossible because the zlib deflate stream should only ever surface `Other`-kind errors. If the zlib backend ever returns a differently-classified I/O error, the library authors consider it a bug in the zlib integration and intentionally panic.

Solutions

1. Update gix-pack, gix-zlib and flate2 to the latest versions (the panic indicates an unhandled zlib error classification that may already be fixed).
2. Capture the full panic message including the `{:?}` of the error and file an issue against gitoxide with the error kind.
3. As a workaround, reduce memory pressure / retry the pack operation; if reproducible, try a different zlib feature (e.g. zlib-ng vs default) to see if the backend is the cause.

Example fix

// library-side before (panics)
err => {
    unreachable!("Should never see other errors than zlib, but got {:?}", err)
}
// library-side after (propagates instead of panicking)
err => {
    return Err(input::Error::Io(err.into()))
}

// Rust: panic cannot be caught without catch_unwind; wrap the whole pack operation
let result = std::panic::catch_unwind(|| pack_writer.write_stream(...));
match result {
    Ok(inner) => inner?,
    Err(panic) => return Err(anyhow!("zlib compression panicked: {:?}", panic)),
}

When it happens

Trigger: Packing a pack entry via `from_data_obj`/`compress_data` when `std::io::copy` into the zlib `deflate::Write` fails with an io::Error whose kind is not `ErrorKind::Other` (e.g. a platform-level error surfaced by the zlib stream wrapper).

Common situations: A bug or unexpected behavior in the zlib compression backend (gix-zlib / flate2), resource exhaustion (OOM during deflate) that the backend classifies under a non-Other kind, or running with an unusual zlib feature-toggle combination. Practically almost never hit by users; indicates a library-level defect when it happens.

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

• only value and unspecified are possible here
• parent-match assures this
• upper match already assured we only deal with blobs
• fixed size array with three items
• internal nodes have no object ID key

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

Appendix: source

Thrown at gix-pack/src/data/input/entry.rs:64

}

fn to_header(kind: gix_object::Kind) -> Header {
    use gix_object::Kind::*;
    match kind {
        Tree => Header::Tree,
        Blob => Header::Blob,
        Commit => Header::Commit,
        Tag => Header::Tag,
    }
}

fn compress_data(obj: &gix_object::Data<'_>, compression: gix_zlib::Compression) -> Result<Vec<u8>, input::Error> {
    let mut out = gix_zlib::stream::deflate::Write::new(Vec::new(), compression);
    if let Err(err) = std::io::copy(&mut &*obj.data, &mut out) {
        match err.kind() {
            std::io::ErrorKind::Other => return Err(input::Error::Io(err.into())),
            err => {
                unreachable!("Should never see other errors than zlib, but got {:?}", err)
            }
        }
    }
    out.flush().expect("zlib flush should never fail");
    Ok(out.into_inner())
}

View on GitHub (pinned to e73179060b)