What causes "explicit task name was just found" in jdx/mise?

Verify every explicit task is inserted into `tasks` keyed by its own `name` before the alias-extension loop runs

explicit task name was just found

Error message

explicit task name was just found

What it means

mise panics with 'explicit task name was just found' when collecting alias tasks and `tasks.get_mut(&task.name)` returns `None`. The loop has just inserted (or verified) an entry keyed by each explicit task's own name, so looking it up again must succeed; a `None` means the task's name key was not actually present in the map, breaking the alias-collection invariant in config parsing (src/config/mod.rs:1150).

Source

Thrown at src/config/mod.rs:1150

                None => Vec::new(),
            };
            for task in inferred_tasks {
                // Explicit project tasks replace provider inference. Preserve the provider-scoped
                // name as an alias, but never merge provider fields into the explicit definition.
                if tasks.contains_key(&task.name) {
                    let available_aliases = task
                        .aliases
                        .into_iter()
                        .filter(|alias| {
                            !tasks.contains_key(alias)
                                && !tasks
                                    .values()
                                    .any(|explicit| explicit.aliases.contains(alias))
                        })
                        .collect::<Vec<_>>();
                    tasks
                        .get_mut(&task.name)
                        .expect("explicit task name was just found")
                        .aliases
                        .extend(available_aliases);
                    continue;
                }
                let explicit_name = task
                    .aliases
                    .iter()
                    .find(|alias| tasks.contains_key(*alias))
                    .cloned()
                    .or_else(|| {
                        task.aliases.iter().find_map(|alias| {
                            tasks.iter().find_map(|(name, explicit)| {
                                (explicit.file.is_some() && strip_task_extension(name) == alias)
                                    .then(|| name.clone())
                            })
                        })
                    })
                    .or_else(|| {

View on GitHub (pinned to afd2eddd3a)

Solutions

Verify every explicit task is inserted into `tasks` keyed by its own `name` before the alias-extension loop runs
Check for duplicate task names across config files that could overwrite the earlier entry
If name can change, look up the entry by the same key used at insertion time rather than re-deriving `task.name`
Make the insertion a `shift_insert`/entry API immediately adjacent to the get_mut so the invariant is locally obvious

Example fix

// before
tasks.entry(task.name.clone()).or_insert_with(|| task.clone())
    .aliases.extend(available_aliases);
// (original) get_mut panics if key missing
tasks.get_mut(&task.name).expect("explicit task name was just found")
     .aliases.extend(available_aliases);

Defensive patterns

Strategy: type-guard

Validate before calling

if !tasks.contains_key(&task.name) { return Err(anyhow!("task {} missing from map before alias merge", task.name)); }

Type guard

fn get_task<'a>(tasks: &'a mut Tasks, name: &str) -> Option<&'a mut Task> { tasks.get_mut(name) }

Prevention

Insert every explicit task under its own name before alias merging
Use the entry API to combine insert and alias extension in one step
Test configs with duplicate/colliding task names

When it happens

Trigger: Parsing mise task files where a task's aliases are being merged into the explicit task entry, but the earlier insertion keyed under `task.name` was skipped or the name was mutated between insert and lookup — e.g. duplicate task definitions, a task defined only via an alias, or a refactor changing how explicit tasks are first inserted into `tasks`.

Common situations: A mise.toml or task file defines a task whose `name` differs from the key it was inserted under; two files define tasks that collide on name and the second overwrites/removes the first; a contributor changes the insertion loop upstream of the alias merge.

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

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