operation {} still needs attention; its pending record was p

Error message

operation {} still needs attention; its pending record was preserved

What it means

Thrown after attempting to recover an operation when the operation's pending record still exists in the pending store. scope::recover_operation did not fully consume the pending record, meaning the operation still requires user attention and the recovery attempt is reported as incomplete.

Source

Thrown at src/cli/dotfiles/recover.rs:97

            bail!("select one operation by its identifier before accepting current files");
        }
        if self.keep_current
            && !self.yes
            && !crate::ui::prompt::confirm(
                "Keep these live files and discard this operation's temporary recovery copies?",
            )?
            .is_yes()
        {
            info!("dotfiles: recovery copies preserved");
            return Ok(());
        }
        for (_, record) in selected {
            scope::recover_operation(&store, tracked, &record.checkpoint.uuid, self.keep_current)?;
            if store::list_pending_in(store.state_dir())?
                .iter()
                .any(|(_, pending)| pending.checkpoint.uuid == record.checkpoint.uuid)
            {
                bail!(
                    "operation {} still needs attention; its pending record was preserved",
                    record.checkpoint.uuid
                );
            }
            info!("dotfiles: recovered operation {}", record.checkpoint.uuid);
        }
        Ok(())
    }
}

fn matches_operation(selector: &str, id: u64, uuid: &str) -> bool {
    selector.parse::<u64>().ok() == Some(id) || uuid.starts_with(selector)
}

#[cfg(test)]
mod tests {
    use super::matches_operation;

View on GitHub (pinned to afd2eddd3a)

Solutions

Re-run `mise bootstrap dotfiles history --pending` and inspect what still needs attention for that uuid
Resolve the underlying conflict (accept or discard the operation's files) then recover again
Run recover with --yes or --keep-current to give the resolver a definite answer
If state looks corrupt, back up the history state directory and re-run recovery

Example fix

// before
mise bootstrap dotfiles history --recover <op-id>  # still needs attention
// after
mise bootstrap dotfiles history --recover <op-id> --keep-current --yes

Defensive patterns

Strategy: retry

Validate before calling

# after recovery, confirm the uuid no longer appears in --pending
mise bootstrap dotfiles history --pending | grep -q "$OP_UUID" && echo "still pending"

Try / catch

for attempt in 1 2 3; do
  mise bootstrap dotfiles history --recover "$OP_ID" --yes && break
  sleep 1
done
mise bootstrap dotfiles history --pending | grep -q "$OP_UUID" && exit 1

Prevention

Re-verify --pending after every recovery attempt
Resolve file conflicts (choose keep/discard) before recovering
Avoid running concurrent mise dotfiles commands on the same machine

When it happens

Trigger: Calling recover for an operation whose uuid still appears in store::list_pending_in(store.state_dir()) after scope::recover_operation ran — e.g. recovery was partial or the operation re-flagged itself as pending.

Common situations: Recover hitting a conflicting live file it cannot resolve, leaving the record pending; concurrent mise processes touching the pending store; corrupted recovery state.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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