rust-lang/cargo · critical

parent not currently active!?

Error message

parent not currently active!?

What it means

Invariant in the dependency resolver's conflict-resolution (`find_candidate`): when iterating parents of the critical (conflicting) activation, it calls `cx.is_active(**p).expect("parent not currently active!?")`. The resolver assumes any parent recorded in the `parents` graph of an active node is itself active.

Source

Thrown at src/resolver/mod.rs:842

            .map(|&c| cx.is_active(c).map(|a| (a, c))),
    )?;
    let backtrack_critical_reason: ConflictReason =
        conflicting_activations[&backtrack_critical_id].clone();

    if cx
        .parents
        .is_path_from_to(&parent.package_id(), &backtrack_critical_id)
    {
        // We are a descendant of the trigger of the problem.
        // The best generalization of this is to let things bubble up
        // and let `backtrack_critical_id` figure this out.
        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(

View on GitHub (pinned to 0e07a15537)

Solutions

1. Report a cargo bug with the minimal `Cargo.toml`/`Cargo.lock` that reproduces the panic.
2. Try the alternate resolver (`resolver = "2"` or `= "1"`) in the root manifest to dodge the buggy path.
3. Pin or relax specific dependency versions to change the backtracking shape and avoid the trigger.
4. Update cargo — resolver invariants are fixed promptly.

// No caller-side pre-check; mitigate by changing resolver behavior.
// In Cargo.toml root:
// [package]
// resolver = "2"   # or "1" to avoid the buggy backtracking path

When it happens

Trigger: Fires if the resolver's context graph has a parent edge to a node that `is_active` reports as inactive — i.e. the `parents` graph and the active-set have diverged. This is a deep resolver-internal consistency bug, typically introduced by a backtracking/state-restoration regression.

Common situations: Almost exclusively a cargo resolver bug; surfaced on complex dependency graphs with heavy backtracking (large workspaces, conflicting `links`, version conflicts). End-user config rarely causes it; a particular `Cargo.lock`/graph may reproducibly trip it.

Related errors

• an already used dep now pending!?
• 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/17fc558a0d9afc28.json. Report an issue: GitHub.