What causes "remote action output tree is too large" in jdx/mise?

Shrink the action's cached outputs or exclude the oversized tree from caching

jdx/mise · error · eyre::Report

remote action output tree is too large

Error message

remote action output tree is too large

What it means

validate_prefetched_action walks the output_root directory DAG (BFS over directories), dedupes digests via a `seen` map, and aborts once it exceeds MAX_PREFETCH_DIRECTORY_OBJECTS (100,000). The bound protects the agent from unbounded memory/work when a cached output tree is enormous.

Source

Thrown at crates/mise-cache-core/src/agent.rs:1253

                    }
                }
            } else if !verified.contains_key(metadata) {
                bail!("remote action metadata is missing");
            }
        }
        let mut pending = action
            .result
            .output_root
            .iter()
            .cloned()
            .collect::<Vec<_>>();
        let mut seen = BTreeMap::new();
        while let Some(digest) = pending.pop() {
            if seen.insert(digest.clone(), ()).is_some() {
                continue;
            }
            if seen.len() > MAX_PREFETCH_DIRECTORY_OBJECTS {
                bail!("remote action output tree is too large");
            }
            let directory = directories
                .get(&digest)
                .ok_or_else(|| eyre::eyre!("remote action output directory is missing"))?;
            for file in &directory.files {
                if !verified.contains_key(&file.digest) {
                    bail!("remote action output file is missing");
                }
            }
            pending.extend(
                directory
                    .directories
                    .iter()
                    .map(|directory| directory.digest.clone()),
            );
        }
        Ok(())
    }

View on GitHub (pinned to 6f52dcdf99)

Solutions

Shrink the action's cached outputs or exclude the oversized tree from caching
Split the action so each cached result stays under 100k directory objects
If unexpected, inspect what the action actually wrote into its output root — usually a bug generating a huge tree

Defensive patterns

Strategy: validation

Validate before calling

// Before storing/prefetching, bound the output tree yourself
const MAX_DIR_OBJECTS: usize = 100_000;
fn count_directory_objects(root: &Path) -> std::io::Result<usize> {
    let mut n = 0;
    for entry in walkdir::WalkDir::new(root) { entry?; n += 1; }
    Ok(n)
}
assert!(count_directory_objects(&output_root)? <= MAX_DIR_OBJECTS);

Prevention

Keep cached output roots small and focused; move bulky generated trees outside the cached output
Audit actions that write into output roots recursively — runaway generation hits this cap
Remember cycles are deduped but sheer object count is not; 100,001 distinct directories trips it

When it happens

Trigger: A cached action whose output tree contains more than 100,000 distinct directory objects — e.g. full build trees, vendored dependencies inside outputs, or an accidental cache of a huge directory.

Common situations: Caching actions with massive/recursive outputs; a task bug writing generated trees into the cached output root; pathological or hostile cache entries designed to blow up traversal.

Related errors

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