diem/diem · error

IPE: Cyclic dependency found after resolution {:?}

Error message

IPE: Cyclic dependency found after resolution {:?}

What it means

BuildPlan::create runs a topological sort (petgraph toposort) over the resolved package dependency graph and bails if it contains a cycle. Since resolution should reject cycles earlier, hitting this is flagged as an internal error (IPE = internal programmer error), but it still means the package graph has a circular dependency.

Source

Thrown at language/tools/move-package/src/compilation/build_plan.rs:25

};
use anyhow::Result;
use petgraph::algo::toposort;
use std::{collections::BTreeMap, io::Write};

#[derive(Debug, Clone)]
pub struct BuildPlan {
    root: PackageName,
    sorted_deps: Vec<PackageName>,
    resolution_graph: ResolvedGraph,
}

impl BuildPlan {
    pub fn create(resolution_graph: ResolvedGraph) -> Result<Self> {
        let mut sorted_deps = match toposort(&resolution_graph.graph, None) {
            Ok(nodes) => nodes,
            Err(err) => {
                // Is a DAG after resolution otherwise an error should be raised from that.
                anyhow::bail!("IPE: Cyclic dependency found after resolution {:?}", err)
            }
        };

        sorted_deps.reverse();

        Ok(Self {
            root: resolution_graph.root_package.package.name,
            sorted_deps,
            resolution_graph,
        })
    }

    pub fn compile<W: Write>(&self, writer: &mut W) -> Result<CompiledPackage> {
        let package_root = &self.resolution_graph.package_table[&self.root];
        let project_root = &package_root.package_path;
        let mut compiled: BTreeMap<PackageName, CompiledPackage> = BTreeMap::new();
        for package_ident in &self.sorted_deps {
            let resolved_package = self.resolution_graph.get_package(package_ident);

View on GitHub (pinned to fc4714a8ea)

Solutions

  1. Inspect your Move.toml files and remove the circular dependency (A→B and B→A cannot both hold); restructure shared code into a third package
  2. Run `move package update-deps` / re-resolve dependencies after edits so the resolution graph is rebuilt cleanly
  3. Check transitive deps: the cycle may be between dependencies, not your own packages — inspect the cycle nodes listed in the error message
  4. If you believe resolution should have caught this, file a bug with the package manifests; the resolver is expected to reject cycles with a proper error

Example fix

// before (Move.toml)
# pkg_a: [dependencies] pkg_b = { local = "../pkg_b" }
# pkg_b: [dependencies] pkg_a = { local = "../pkg_a" }
// after
# pkg_a: [dependencies] pkg_b = { local = "../pkg_b" }
# pkg_b: (no dependency on pkg_a; move shared types into pkg_common)
Defensive patterns

Strategy: validation

Validate before calling

// Before creating a build plan, ensure the resolution graph is acyclic:
use petgraph::algo::is_cyclic_directed;
fn ensure_acyclic(graph: &petgraph::graphmap::DiGraphMap<Package, ()>) -> Result<(), String> {
    if is_cyclic_directed(graph) { Err("dependency graph contains a cycle".into()) } else { Ok(()) }
}

Type guard

fn is_dag(graph: &petgraph::Graph<String, ()>) -> bool {
    !petgraph::algo::is_cyclic_directed(graph)
}

Try / catch

let sorted_deps = toposort(&resolution_graph.graph, None)
    .map_err(|err| anyhow::anyhow!("IPE: Cyclic dependency found after resolution {:?} — check Move.toml for circular [dependencies]", err))?;

Prevention

When it happens

Trigger: Calling BuildPlan::create with a ResolvedGraph whose `graph` contains a dependency cycle — e.g. package A depends on B and B depends on A.

Common situations: Hand-edited Move.toml files creating mutual [dependencies], git dependency pins updated to versions that reference each other, or a bug/edge case in dependency resolution that let a cycle through.

Related errors


AI-assisted analysis of diem/diem@fc4714a8ea (2026-09-04). Data as JSON: /api/errors/fd20deaac327c80a. Report an issue: GitHub.