fix(executions): Fixing Process Exit Code

[xoscar]

Fixing Process Exit Code

The execution code was sending SIGKILL to the child processes, causing the cleanup code to never be executed. The side effects of this caused parallel runs to stay in progress forever.

Checklist (choose whats happened)

• breaking change! (describe)
• tested locally
• tested on cluster
• added new dependencies
• updated the docs
• added a test

Fixes

• Fixes exit code for child processes

[greptile-apps]

Greptile Summary

This PR fixes parallel test runs getting stuck by changing the context-cancellation signal from the default SIGKILL to SIGTERM (with a 10-second SIGKILL fallback via WaitDelay), allowing child-process cleanup/deferred code to run. getProcessStatus is updated to treat "signal: terminated" the same as "signal: killed" so the abort-propagation logic fires correctly in both cases.

Confidence Score: 5/5

Safe to merge — targeted fix with no logic errors or regressions introduced.

Both changes are straightforward and correct: the Cancel closure is only invoked after cmd.Start() succeeds (so cmd.Process is never nil), WaitDelay provides a sensible hard-kill fallback, and the getProcessStatus update keeps abort-detection consistent with the new signal. No new failure modes introduced.

No files require special attention.

Important Files Changed

Filename	Overview
cmd/testworkflow-init/orchestration/executions.go	Replaces default SIGKILL on context cancellation with SIGTERM + 10s WaitDelay, and updates getProcessStatus to treat SIGTERM the same as SIGKILL for abort detection.

Sequence Diagram

sequenceDiagram
    participant Ctx as Context
    participant Cmd as exec.Cmd (CreateWithContext)
    participant Proc as Child Process
    participant Run as execution.Run()

    Ctx->>Cmd: ctx.Done() fires
    Note over Cmd: Cancel() called (was: os.Kill / SIGKILL)
    Cmd->>Proc: SIGTERM (new behaviour)
    Proc->>Proc: cleanup / deferred code runs
    alt exits within 10s (WaitDelay)
        Proc-->>Run: Wait() returns "signal: terminated"
        Run->>Run: getProcessStatus → aborted=true
        Run->>Run: group.Abort() if not already aborted
    else still running after 10s
        Cmd->>Proc: SIGKILL (WaitDelay fallback)
        Proc-->>Run: Wait() returns "signal: killed"
        Run->>Run: getProcessStatus → aborted=true
    end

Loading

_{Reviews (2): Last reviewed commit: "cleanup" | Re-trigger Greptile}

[Copilot]

Pull request overview

This PR adjusts how testworkflow-init cancels child process executions so that child processes receive a graceful termination signal (allowing cleanup hooks to run) instead of being hard-killed, addressing stuck “in progress” parallel runs.

Changes:

• Override exec.Cmd.Cancel to send SIGTERM on context cancellation.
• Configure a WaitDelay to give processes time to exit cleanly before escalation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mgazza]

Code review

Found 1 issue:

1. getProcessStatus only recognizes "signal: killed" (SIGKILL) as an abort indicator. With Cancel now sending SIGTERM, a child process that does not trap SIGTERM exits with "signal: terminated", which falls into the exitCode < 0 branch in Run() and prints the misleading "The process has been corrupted: signal: terminated." message. The fix is to extend the check to also match "signal: terminated" — e.g. details == "signal: killed" || details == "signal: terminated". (Copilot and Greptile flagged the same issue independently.)

testkube/cmd/testworkflow-init/orchestration/executions.go

Lines 275 to 277 in 8723cc5

	details := e.String()
	return details == "signal: killed", details, e.ExitCode()
	}

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[xoscar]

@greptile

[xoscar]

Thanks @mgazza, do you mind taking a look again?