jdx/mise · error

edits: "{}": {reason}, fix the file manually

Error message

edits: "{}": {reason}, fix the file manually

What it means

When physically removing a managed block from a file during unapply, unapply_one calls find_block to locate the exact begin/end lines for the request's id and comment style. If find_block returns an error reason (e.g. the markers are ambiguous, mismatched, or the target is a symlink case handled earlier), mise bails telling the user to fix the file manually rather than risk deleting the wrong lines.

Source

Thrown at src/system/edits.rs:1050

        "edits: unapplied {}",
        todo.iter()
            .map(|plan| format!("{} ({})", plan.req.path_raw, plan.req.describe_op()))
            .collect::<Vec<_>>()
            .join(", ")
    );
    Ok(())
}

fn unapply_one(req: &EditRequest) -> Result<()> {
    let text = file::read_to_string(&req.path)?;
    let lines = text_lines(&text);
    let remove = match &req.op {
        EditOp::Block { comment, .. } => {
            let refs = lines.iter().map(|line| line.content).collect::<Vec<_>>();
            match find_block(&refs, &req.id, comment) {
                Ok(Some((begin, end))) => lines[begin].start..lines[end].end,
                Ok(None) => return Ok(()),
                Err(reason) => bail!(
                    "edits: \"{}\": {reason}, fix the file manually",
                    req.path_raw
                ),
            }
        }
        EditOp::Line { line, position } => {
            // Use the occurrence nearest the configured insertion edge as the
            // best stateless approximation of the line mise added.
            let found = match position {
                LinePosition::Prepend => lines.iter().find(|candidate| candidate.content == line),
                LinePosition::Append => lines.iter().rfind(|candidate| candidate.content == line),
            };
            if let Some(found) = found {
                found.start..found.end
            } else {
                return Ok(());
            }
        }

View on GitHub (pinned to afd2eddd3a)

Solutions

1. Open the file listed in the error and manually delete the managed block (from its begin marker to its end marker).
2. Alternatively re-run the corresponding `edits apply` so markers are rewritten to the current config, then unapply again.
3. Align the block's comment style/id in mise.toml with what is actually in the file, then unapply.

Example fix

// before: file has stale/missing markers
// some code

// after: manually delete the managed block between markers
// # mise:begin <id>
// ...
// # mise:end <id>
// (removed) — or re-apply first: $ mise edits apply && mise edits unapply

# verify both markers exist for the block id before unapplying
grep -c 'mise:begin my-block' file && grep -c 'mise:end my-block' file

When it happens

Trigger: execute_unapply → unapply_one on an EditOp::Block request where find_block(&refs, &req.id, comment) returns Err(reason): the block markers in the file don't match what mise expects (wrong id, changed comment style/marker wording, nested or overlapping blocks).

Common situations: The user (or a formatter) edited the managed block, removed/altered the begin/end marker comments, or changed the comment style in config so the markers no longer match the file content; unapply then cannot locate the block.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

• edits: cannot unapply these entries: {}
• target changed after unapply planning
• files: cannot unapply these entries:\n{}
• [dotfiles]."{}/{}": block content may not contain its own ma
• edits: cannot diff these entries, fix them manually: {}

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/78cefdc699fcbc90. Report an issue: GitHub.