rust-lang/cargo · critical

an already used dep now pending!?

Error message

an already used dep now pending!?

What it means

Invariant adjacent to 318: `registry.query(critical_parents_dep, first_version).expect("an already used dep now pending!?").expect("an already used dep now error!?")`. During conflict-resolution, the resolver re-queries a dependency it believes was already resolved; it assumes the query cannot fail (pending) and cannot error.

Source

Thrown at src/resolver/mod.rs:854

        return None;
    }
    // What parents does that critical activation have
    for (critical_parent, critical_parents_deps) in
        cx.parents.edges(&backtrack_critical_id).filter(|(p, _)| {
            // it will only help backjump further if it is older then the critical_age
            cx.is_active(**p).expect("parent not currently active!?") < backtrack_critical_age
        })
    {
        for critical_parents_dep in critical_parents_deps.iter() {
            // We only want `first_version.is_some()` for direct dependencies of workspace
            // members which isn't the case here as this has a `parent`
            let first_version = None;
            // A dep is equivalent to one of the things it can resolve to.
            // Thus, if all the things it can resolve to have already ben determined
            // to be conflicting, then we can just say that we conflict with the parent.
            if let Some(others) = registry
                .query(critical_parents_dep, first_version)
                .expect("an already used dep now pending!?")
                .expect("an already used dep now error!?")
                .iter()
                .rev() // the last one to be tried is the least likely to be in the cache, so start with that.
                .map(|other| {
                    past_conflicting_activations
                        .find(
                            dep,
                            &|id| {
                                if id == other.package_id() {
                                    // we are imagining that we used other instead
                                    Some(backtrack_critical_age)
                                } else {
                                    cx.is_active(id)
                                }
                            },
                            Some(other.package_id()),
                            // we only care about things that are newer then critical_age
                            backtrack_critical_age,

View on GitHub (pinned to 0e07a15537)

Solutions

1. Report a cargo bug with the reproducer (`Cargo.toml`, lockfile, registry config).
2. Switch resolver version (`resolver = "1"`/`"2"`) or adjust `[patch]` to alter the query path.
3. Pin dependency versions to reduce backtracking and avoid the conflicting branch.
4. Update cargo and clear the registry index cache before retrying.

// No direct pre-check; sidestep by altering resolver/query inputs.
// In Cargo.toml root:
// [package]
// resolver = "2"
// And pin or relax the dependency that triggers repeated backtracking.

When it happens

Trigger: Fires if `registry.query` returns `Err` (the second expect) or a pending/`None` state (the first expect) for a dependency the resolver previously treated as resolved — indicating the registry/source state changed mid-resolution or a query bug.

Common situations: Cargo resolver bug surfaced on intricate graphs; a registry index updated mid-build (rare); a `[patch]`/`[replace]` whose query semantics changed between calls; a source-rewrite that returns different candidates for the same query. Users see it as a panic during dependency resolution.

Related errors

• parent not currently active!?
• We've already checked that there is exactly one.
• source ID should have valid URLs
• in the non-empty branch
• packages downloaded

AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/9b8aaf5e22785354.json. Report an issue: GitHub.