What's wrong
In Essentials.CommandExecutors.Native/NativeCommandExecutor.cs, ExecuteAsync awaits process.WaitForExitAsync(cancellationToken) (~L74). When the token fires, the catch (OperationCanceledException) (~L84) returns Cancelled(), and the using then disposes the Process. Disposing does not terminate the child, so it keeps running.
The synchronous Execute path calls TryKill(process) on cancellation (~L145), so the two paths disagree.
Repro (Linux, net10.0)
ICommandExecutor ex = new NativeCommandExecutor();
using var cts = new CancellationTokenSource(500);
var r = await ex.ExecuteAsync($"sleep 3; touch {marker}", null, cts.Token);
await Task.Delay(4000);
Console.WriteLine(File.Exists(marker));
Observed:
async cancel returned after 505ms: exit=-1 err=[Operation was cancelled.]
async: marker exists after cancel? True
sync: marker exists after cancel? False // same command through Execute(...)
Expected: the async path kills the command like the sync path does, so the marker is never created.
Why it matters
The caller is told the command was cancelled, but it runs to completion and performs its side effects, such as writes, deploys or network calls. Long-running or looping commands are orphaned for good.
Suggested fix
In the OperationCanceledException handler (or via cancellationToken.Register), kill the process before returning: process.Kill(entireProcessTree: true) on net5+, and the existing TryKill on older targets. Add an async counterpart of the existing sync cancellation test.
What's wrong
In
Essentials.CommandExecutors.Native/NativeCommandExecutor.cs,ExecuteAsyncawaitsprocess.WaitForExitAsync(cancellationToken)(~L74). When the token fires, thecatch (OperationCanceledException)(~L84) returnsCancelled(), and theusingthen disposes theProcess. Disposing does not terminate the child, so it keeps running.The synchronous
Executepath callsTryKill(process)on cancellation (~L145), so the two paths disagree.Repro (Linux, net10.0)
Observed:
Expected: the async path kills the command like the sync path does, so the marker is never created.
Why it matters
The caller is told the command was cancelled, but it runs to completion and performs its side effects, such as writes, deploys or network calls. Long-running or looping commands are orphaned for good.
Suggested fix
In the
OperationCanceledExceptionhandler (or viacancellationToken.Register), kill the process before returning:process.Kill(entireProcessTree: true)on net5+, and the existingTryKillon older targets. Add an async counterpart of the existing sync cancellation test.