jdx/mise · error

affected project exists in graph

Error message

affected project exists in graph

What it means

`mise run --affected` (experimental monorepo workspaces) computes the set of affected projects from git revisions and then renders machine-readable JSON. Every affected project id was produced by enumerating the same WorkspaceProjectGraph, so `graph.get(id)` in display_affected_json must succeed; the expect asserts the AffectedProjects set and the graph passed to the renderer stayed in sync (src/cli/run.rs:450-462).

Source

Thrown at src/cli/run.rs:450

#[derive(Serialize)]
struct AffectedTaskOutput<'a> {
    name: &'a str,
    projects: Vec<&'a crate::task::workspace::ProjectId>,
}

fn display_affected_json(
    revisions: &crate::task::workspace::git::WorkspaceGitRevisions,
    workspace_root: &std::path::Path,
    graph: &crate::task::workspace::WorkspaceProjectGraph,
    affected: &crate::task::workspace::AffectedProjects,
    tasks: &[Task],
) -> Result<()> {
    let mut projects_by_root = BTreeMap::<PathBuf, Vec<_>>::new();
    let projects = affected
        .projects()
        .map(|(id, reasons)| {
            let project = graph.get(id).expect("affected project exists in graph");
            projects_by_root
                .entry(crate::file::desymlink_path(
                    &workspace_root.join(&project.root),
                ))
                .or_default()
                .push(id);
            AffectedProjectOutput {
                id,
                root: &project.root,
                reasons,
            }
        })
        .collect();
    let mut tasks = tasks
        .iter()
        .map(|task| AffectedTaskOutput {
            name: &task.display_name,
            projects: task

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. If hit: rerun `mise run --affected` — a transient workspace/graph race in an experimental feature; update to the latest mise
2. Disable the experimental workspace feature (settings: experimental = false) if it recurs
3. As a contributor: derive AffectedProjects and the display graph from the same graph instance; never rebuild between compute and render
4. Report at https://github.com/jdx/mise/issues with the workspace layout and revisions used

Example fix

// before: graph recomputed between affected computation and display
let affected = compute_affected(&graph_refresh().await?, revs);
display_affected_json(revs, root, &graph_refresh().await?, &affected, tasks)?; // ids may not exist -> panic

// after: one graph instance flows through both
let graph = workspace_graph().await?;
let affected = compute_affected(&graph, revs);
display_affected_json(revs, root, &graph, &affected, tasks)?;

When it happens

Trigger: Only if the affected set and the graph handed to display_affected_json come from different builds/refreshes of the workspace graph — e.g. a refactor caches or recomputes the graph between computation and display. User-side flag combinations (--affected with revisions, --json) always pass the same graph instance.

Common situations: Contributors changing workspace graph caching/incremental refresh; users on experimental monorepo builds after a mid-run workspace change (added/removed project) is theoretically where a stale-graph refactor bug would show.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• BootstrapPart values have clap names
• bootstrap command is registered
• failed to discover workspace providers: {error}
• brew-cask: internal non-terminate flight step
• {err}

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/513aa25ee4d6521d. Report an issue: GitHub.