FuelLabs/sway · error · anyhow::Error
dependency of {:?} named {:?} is invalid: {}
Error message
dependency of {:?} named {:?} is invalid: {} What it means
Thrown while forc walks the dependency graph during fetch/build planning: after adding an edge to a dependency node, it calls validate_dep_manifest on the dependency's manifest. If that validation fails (malformed tables, invalid entries, missing sections), the error is wrapped with the parent package name and the dependency name, so the failing edge of the graph is identified.
Source
Thrown at forc-pkg/src/pkg.rs:1526
added.insert(dep_node);
*entry.insert(dep_node)
}
};
let dep_edge = Edge::new(dep_name.to_string(), dep_kind.clone());
// Ensure we have an edge to the dependency.
graph.update_edge(node, dep_node, dep_edge.clone());
// If we've visited this node during this traversal already, no need to traverse it again.
if !visited.insert(dep_node) {
continue;
}
let dep_pinned = &graph[dep_node];
let dep_pkg_id = dep_pinned.id();
validate_dep_manifest(dep_pinned, &manifest_map[&dep_pkg_id], &dep_edge).map_err(|e| {
let parent = &graph[node];
anyhow!(
"dependency of {:?} named {:?} is invalid: {}",
parent.name,
dep_name,
e
)
})?;
let path_root = match dep_pinned.source {
source::Pinned::Member(_)
| source::Pinned::Git(_)
| source::Pinned::Ipfs(_)
| source::Pinned::Registry(_) => dep_pkg_id,
source::Pinned::Path(_) => path_root,
};
// Fetch the children.
added.extend(fetch_deps(
fetch_id,View on GitHub (pinned to 47e5e902fa)
Solutions
- Read the tail of the message: the text after 'is invalid:' is the underlying validate_dep_manifest cause - fix that in the named dependency's Forc.toml
- Verify the dependency key in [dependencies] exactly matches the [project].name inside the dependency's own Forc.toml
- If the dependency comes from git/ipfs, update to a rev/tag/cid where its manifest is valid for your forc version
- Re-run forc build (or forc check) from the workspace root to confirm the whole graph validates
Example fix
# dependency's Forc.toml - before [project] authros = ["me"] name = "my_lib" # after [project] authors = ["me"] name = "my_lib" entry = "lib.sw"
Defensive patterns
Strategy: try-catch
Try / catch
match forc_pkg::build_with_options(&opts) {
Ok(built) => { /* ... */ }
Err(e) if e.to_string().starts_with("dependency of") => {
// message contains parent pkg name, dep name and root cause after 'is invalid:'
eprintln!("invalid dependency manifest: {e:#}");
std::process::exit(1);
}
Err(e) => return Err(e),
} Prevention
- Validate every dependency's Forc.toml with PackageManifestFile::from_file plus field checks before constructing a BuildPlan
- Pin git dependencies to a rev you have already built successfully
- Run forc check after editing manifests of workspace members
When it happens
Trigger: Building any manifest whose dependency (path, git, ipfs, registry or workspace member) has a Forc.toml that fails validate_dep_manifest - e.g. a misspelled table key, a dependency entry missing required fields, or an invalid [project] section inside the dependency's manifest.
Common situations: Adding a git or path dependency whose Forc.toml is malformed or written for a different forc version; editing a workspace member's manifest while other packages depend on it; upgrading forc which tightened manifest validation rules.
Related errors
- the dependency `{}` could not be found in `{}`
- failed to find package `{}` in {}
- failed to write toml file: {}
- hex salt declaration needs to start with 0x
- {e}
AI-assisted analysis of FuelLabs/sway@47e5e902fa (2026-08-16).
Data as JSON: /api/errors/8ff9fcdfdd91f7d1.
Report an issue: GitHub.