fix(tasks): prevent hang when task fails in sequence

[jdx]

Summary

• Fixes task sequences hanging when a task fails
• Ensures proper error propagation in task sequences
• Adds support for --continue-on-error flag in sequences

Problem

When running tasks in sequence (e.g., [{task = "task1"}, {task = "task2"}]), if a task failed, the entire task run would hang indefinitely instead of properly exiting with an error.

Root Cause

The inject_and_wait method was waiting for all tasks to complete via a done_rx channel, but the scheduler would stop processing new tasks when is_stopping() returned true, preventing the channel from receiving its completion signal.

Solution

1. Updated scheduler to only stop when is_stopping() && !continue_on_error instead of just is_stopping()
2. Simplified inject_and_wait to properly handle task failures
3. Added comprehensive e2e test for both normal and --continue-on-error cases

Test plan

• Added e2e test test_task_sequence_failure that verifies:
  • Task sequences stop on failure by default (exit code 1, subsequent tasks don't run)
  • Task sequences continue with --continue-on-error flag (exit code 1, but subsequent tasks do run)
• All existing task tests pass

Fixes: #6257

🤖 Generated with Claude Code

[Copilot]

Pull Request Overview

This PR fixes task sequences hanging when a task fails by updating the scheduler logic to respect the --continue-on-error flag and ensuring proper error propagation.

• Modified scheduler to only stop when both is_stopping() is true AND continue_on_error is false
• Added error checking in inject_and_wait method to properly handle task sequence failures
• Added comprehensive e2e test to verify both failure scenarios and --continue-on-error behavior

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/cli/run.rs	Updated scheduler stopping conditions and added error handling in task sequence execution
e2e/tasks/test_task_sequence_failure	Added comprehensive test for task sequence failure handling and continue-on-error behavior

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The error message 'task sequence aborted due to failure' is generic and doesn't provide specific information about which task failed or why. Consider including the actual failure reason or task name to help users debug the issue.

Suggested change

	return Err(eyre!("task sequence aborted due to failure"));
	// Try to provide more context about the failure
	let sub_deps_locked = sub_deps.lock().await;
	if let Some((failed_task, fail_error)) = sub_deps_locked.last_failed_task_with_error() {
	return Err(eyre!(
	"task sequence aborted due to failure in task '{}': {}",
	failed_task.name,
	fail_error
	));
	} else {
	return Err(eyre!("task sequence aborted due to failure (no further details available)"));
	}

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2025.9.7 x -- echo	19.8 ± 0.4	18.6	21.5	1.00
mise x -- echo	20.2 ± 0.7	18.8	23.8	1.02 ± 0.04

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2025.9.7 env	19.0 ± 0.6	18.1	26.9	1.00
mise env	20.0 ± 0.5	19.3	24.9	1.05 ± 0.04

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2025.9.7 hook-env	19.3 ± 0.4	18.5	24.3	1.00
mise hook-env	20.1 ± 0.3	19.4	21.1	1.04 ± 0.03

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2025.9.7 ls	17.5 ± 0.2	17.0	18.1	1.00
mise ls	18.0 ± 0.3	17.4	22.0	1.03 ± 0.02

xtasks/test/perf

Command	mise-2025.9.7	mise	Variance
install (cached)	170ms	✅ 107ms	+58%
ls (cached)	64ms	65ms	-1%
bin-paths (cached)	71ms	72ms	-1%
task-ls (cached)	502ms	507ms	+0%

✅ Performance improvement: install cached is 58%