What causes "no pending operation {uuid}" in jdx/mise?

Run the command again and pick a pending operation from the current list instead of typing the uuid by hand

no pending operation {uuid}

Error message

no pending operation {uuid}

What it means

recover_operation looks up pending operation records by checkpoint UUID and refuses when none match. The requested pending operation does not exist (or is no longer pending), so there is nothing to recover.

Source

Thrown at src/system/history/scope.rs:746

/// with one reserved id.
pub(crate) fn recover_stale(store: &Store, tracked: &TrackedSet) -> Result<()> {
    recover_records(store, tracked, store::list_pending_in(store.state_dir())?)
}

/// Retry a single operation under the caller's recovery lock. Accepting live
/// files is deliberately separate from ordinary automatic recovery.
pub(crate) fn recover_operation(
    store: &Store,
    tracked: &TrackedSet,
    uuid: &str,
    keep_current: bool,
) -> Result<()> {
    let mut pending = store::list_pending_in(store.state_dir())?
        .into_iter()
        .filter(|(_, record)| record.checkpoint.uuid == uuid)
        .collect::<Vec<_>>();
    if pending.is_empty() {
        bail!("no pending operation {uuid}");
    }
    if keep_current {
        for (_, record) in &mut pending {
            record.recovery = store::RecoveryState::Finished;
            if let Some(operation) = &mut record.checkpoint.operation {
                operation.status = OperationStatus::Failed;
                operation.finished_at = Some(store::now_rfc3339());
                operation.error =
                    Some("current live files explicitly accepted during recovery".into());
            }
            store::write_pending_in(store.state_dir(), record)?;
        }
    }
    recover_records(store, tracked, pending)
}

fn recover_records(
    store: &Store,

View on GitHub (pinned to afd2eddd3a)

Solutions

Run the command again and pick a pending operation from the current list instead of typing the uuid by hand
Verify MISE_STATE_DIR points at the store that actually has the pending operation
List pending operations in the state dir to confirm the uuid exists
If the operation already completed, no recovery is needed

Example fix

// before
mise history recover 6f2a...   # uuid from an old session
// after
mise history recover           # choose from currently pending operations

Defensive patterns

Strategy: validation

Validate before calling

let pending = list_pending_operations(state_dir)?;
if !pending.iter().any(|op| op.uuid == target_uuid) {
    eprintln!("{target_uuid} is not pending; pick from the current list");
}

Try / catch

match recover_operation(uuid) {
    Err(e) if e.to_string().starts_with("no pending operation") => prompt_pick_from_pending_list(),
    other => other,
}

Prevention

Select pending operations from the live list, not from memory/old logs
Confirm MISE_STATE_DIR matches the store you recovered from
Recover operations promptly before cleanup removes them

When it happens

Trigger: Calling recover_operation with a uuid that has no entry in store::list_pending_in — the operation already finished, was cleaned up, the state dir changed, or the uuid is wrong.

Common situations: Recovering an old operation after it was already resolved; pointing MISE_STATE_DIR at a different store; typos in a uuid copied from a prompt or log.

Understand the failure class

Background: Record Not Found Errors: "not found", RecordNotFound, and "was not found" — what they mean and how to fix them — this error's family across 28 libraries.

Related errors

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