Error while waiting for package to be published

[beeb]

Bug description

The CI run for my latest release failed with the following error:

-- Running release-plz release --
2025-08-12T19:40:36.877762Z  INFO using release-plz config file release-plz.toml
2025-08-12T19:44:05.281669Z  INFO waiting for the package lintspec to be published...
2025-08-12T19:58:46.872890Z ERROR failed to release package

Caused by:
    0: timeout while publishing lintspec
    1: failed to update git index
    2: "gix" crate failed. If problems persist, consider deleting `~/.cargo/registry/index/github.com-1ecc6299db9ec823/`
    3: The slotmap turned out to be too small with 32 entries, would need 1 more
Error: failed to release package

The package was correctly published to crates.io using the trusted publisher token I provided, but it got stuck at waiting for the package lintspec to be published (as you can see from the timestamps) then errored out with an error about gix.

I managed to work around the issue by creating the tag manually but that's not ideal and I would like to understand the cause for this failure.

• Would you like to work on a fix? n

To Reproduce

Steps to reproduce the behavior:

1. https://github.com/beeb/lintspec/actions/runs/16919093254/job/47940360826

Expected behavior

A git tag is created for the version.

Environment

Github runner

[ncatelli]

FWIW I've been running into this internally as well. It seems to have manifested in rust 1.85+ and we have not had the issue when pinning to <1.85.

[ncatelli]

FWIW I've been running into this internally as well. It seems to have manifested in rust 1.85+ and we have not had the issue when pinning to <1.85.

Additionally I think it may be bubbling up from frewsxcv/rust-crates-index#181.

[beeb]

Thanks for the info @ncatelli . Unfortunately I'm on 1.88 MSRV at the moment which makes the workaround unfeasible.

[beeb]

Curious why this doesn't use the sparse index? Looks like it's trying to use the git index because of the gix error.

[marcoieni]

I don't know what the issue is and don't have time to debug or fix, but PR welcome 👍

[ncatelli]

Curious why this doesn't use the sparse index? Looks like it's trying to use the git index because of the gix error.

I think that error might be a red herring as it's a static error message from crates-index https://github.com/frewsxcv/rust-crates-index/blob/master/src/error.rs#L10.

I ended up tracking it back to https://github.com/release-plz/release-plz/blob/dd42b2e11ad5df764fe5c3c29b68322eebb1ec30/crates/release_plz_core/src/cargo.rs#L91failing for us while updating a private registry, which was a git index. I was able to pull a bit more by appending additional data to the context at that line and recompiling/rerunning it.

[beeb]

@ncatelli In my case I have no private registry and don't use git dependencies, so I would expect release-plz to use this instead

release-plz/crates/release_plz_core/src/cargo.rs

Line 77 in dd42b2e

CargoIndex::Sparse(index) => is_in_cache_sparse(index, package, token).await,

which is why I don't understand getting that error...

[ncatelli]

So I've done additional digging on this and think i found the root cause for my issue with our private registry.

Notably, 1.85.0+ introduced a new hashing format rust-lang/cargo#14917.

A change was added to derive the index hash kind from the cargo version being used https://github.com/release-plz/release-plz/pull/2084/files#diff-7c1b52109b073d495c93cb95833d0732a1ee80659ab31d903bf7a24417cb8124R31-R48. However this isn't uniformly the case. I was able to replicate the issue with a smaller test case.

use crates_index::{GitIndex, HashKind};

const INDEX_URL: &str = "<MY PRIVATE REGISTRY INDEX>";

fn main() -> Result<(), anyhow::Error> {
    for hash_kind in [HashKind::Legacy, HashKind::Stable].iter() {
        let index = GitIndex::from_url_with_hash_kind(INDEX_URL, hash_kind)?;
        let crates_in_index = index.crates().count();
        println!("{hash_kind:?}: {crates_in_index}");
    }

    Ok(())
}

> cargo run
   Compiling gix-debugging v0.1.0
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.57s
     Running `target/debug/gix-debugging`
Legacy: 346
Error: "gix" crate failed. If problems persist, consider deleting `~/.cargo/registry/index/github.com-1ecc6299db9ec823/`

Caused by:
    0: An IO error occurred when talking to the server
    1: Received HTTP status 400
> rustc --version
rustc 1.86.0 (05f9846f8 2025-03-31)

I'm going to investigate if there is a better way for us to either

• Identify the HashKind of the index
• Fallback to HashKind::Legacy if HashKind::Stable fails.

[beeb]

The underlying error here looks different (400 status from the web request). Whereas my original issue was about a wrongly sized slotmap during what I assume is a git index operation.

[ncatelli]

I think you might be right and that we are looking at two separate issues that manifested in that gix error. I'm going to make a separate issue, and PR, for the one I ran into. I believe yours might still be related to the issue called out in #2334 (comment).

[beeb]

Can't reproduce now :)