fix: reliably stop running actions and allow rerunning after stop#219
Merged
fix: reliably stop running actions and allow rerunning after stop#219
Conversation
…ng lifecycle Previously, clicking Stop on a running action would fail to actually stop the underlying process and would prematurely show a 'stopped' status in the UI while the process continued running. Four root causes were identified and fixed: 1. Process group killing: The shell was spawned without its own process group, so SIGTERM only reached the shell process while child processes (npm, cargo, etc.) continued as orphans. Now we call setsid() via pre_exec to create a new session/process group, and send SIGTERM to the negative PID (-pgid) to kill the entire tree. A background thread escalates to SIGKILL after 5 seconds if the group is still alive. 2. Premature UI status: The frontend set status='stopped' immediately in handleStop() before the backend confirmed the process actually exited. Now the frontend waits for the backend's StatusChanged event to update the status, showing 'Stopping...' on a disabled button in the interim. 3. Running map cleanup: stop() previously removed the entry from the running map immediately, which meant the completion thread couldn't find the output buffer to move it to the completed map, losing all buffered output. Now stop() only sends the signal; the completion thread handles all cleanup. 4. Stopped vs Failed status: The completion thread only emitted Completed or Failed based on exit code. Killed processes exit with a signal (no exit code), so they were reported as Failed. Now a 'stopped' HashSet tracks intentional stops, and the completion thread checks it to emit the correct Stopped status. Auto-commit is also skipped for stopped actions.
…n state Previously, after stopping a running action, clicking Run again would show old output instead of starting a fresh execution. Three issues were fixed: 1. handleRunAction() matched any execution for the action regardless of status. Now it only treats status='running' as already-running; for stopped/failed/completed entries it clears the stale state and starts a new run. 2. Stopped and failed actions were never auto-removed from runningActions (only completed ones were). Now all terminal states (completed, failed, stopped) are auto-removed after a brief display delay. 3. When rerunning, old backend output buffers are cleaned up via clearActionExecution() before the new run starts, preventing stale output from appearing. 4. The primary action button only opens the output modal when the action is actively running; otherwise it triggers handleRunAction to start a fresh execution.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix two related issues with the stop-action functionality:
Reliable process termination
setsid()to spawn action processes in their own process group-pid) instead of just the shell, ensuring child processes (npm, cargo, etc.) are also terminated/Tflag with taskkill to kill the process treestoppedset so the completion thread can distinguish intentional stops from crashesStoppedstatus eventAllow rerunning actions after stop
runningstatus entries as blocking a rerun; stopped/failed entries no longer prevent re-execution