Objective
Investigate the signal propagation path in the AWF agent step command to understand exactly why timeout-minutes may not be enforced, and validate or refute this as the root cause.
Context
Issue #23965 reports that timeout-minutes is ignored on the agent step. Initial code analysis suggests the root cause is signal delivery failure through the execution pipeline:
GitHub Actions runner (SIGTERM on timeout)
↓
Bash shell (`set -o pipefail` script)
├─ sudo -E awf ... -- /bin/bash -c '...' ← may not receive SIGTERM
│ └─ AWF Docker container (separate PID namespace)
│ └─ agent process
└─ tee -a ${LOG_FILE} ← pipe may block signal propagation
The command in pkg/workflow/awf_helpers.go builds:
sudo -E awf <args> -- /bin/bash -c '...' 2>&1 | tee -a <logfile>
Potential contributing factors:
- Pipe (
|) breaks SIGTERM chain — tee doesn't forward signals upstream to awf
sudo intercepts signals — sudo may not forward SIGTERM to the awf child
- Docker PID namespace isolation —
awf manages a container; SIGTERM to awf may not propagate into the container
- No
dumb-init/tini in the Dockerfile — Alpine base with gh-aw as entrypoint has no init for signal reaping
Approach
-
Trace the signal path through sudo → awf → Docker container:
- Check if
awf (the firewall binary) handles SIGTERM and forwards it to the container process
- Check if
sudo forwards signals or drops them
- Check Docker signal handling behavior when the host process receives SIGTERM
-
Verify the pipe problem: Write a small shell test confirming that cmd 2>&1 | tee file — when the shell receives SIGTERM — does not reliably kill cmd.
-
Check AWF binary behavior (if source is available or if documentation exists): Does awf handle SIGTERM and issue docker stop/docker kill?
-
Review the set -o pipefail effect: Confirm it only controls exit code propagation, not signal propagation.
Files of Interest
pkg/workflow/awf_helpers.go — BuildAWFCommand() (the pipe construction)
pkg/constants/constants.go — AWFDefaultCommand constant
Dockerfile — confirms no init process
actions/setup/sh/stop_mcp_gateway.sh — example of correct SIGTERM handling with fallback to SIGKILL (pattern to compare against)
Acceptance Criteria
Generated by Plan Command for issue #23965 · ◷
Objective
Investigate the signal propagation path in the AWF agent step command to understand exactly why
timeout-minutesmay not be enforced, and validate or refute this as the root cause.Context
Issue #23965 reports that
timeout-minutesis ignored on the agent step. Initial code analysis suggests the root cause is signal delivery failure through the execution pipeline:The command in
pkg/workflow/awf_helpers.gobuilds:Potential contributing factors:
|) breaks SIGTERM chain —teedoesn't forward signals upstream toawfsudointercepts signals —sudomay not forward SIGTERM to theawfchildawfmanages a container; SIGTERM toawfmay not propagate into the containerdumb-init/tiniin the Dockerfile — Alpine base withgh-awas entrypoint has no init for signal reapingApproach
Trace the signal path through
sudo → awf → Docker container:awf(the firewall binary) handles SIGTERM and forwards it to the container processsudoforwards signals or drops themVerify the pipe problem: Write a small shell test confirming that
cmd 2>&1 | tee file— when the shell receives SIGTERM — does not reliably killcmd.Check AWF binary behavior (if source is available or if documentation exists): Does
awfhandle SIGTERM and issuedocker stop/docker kill?Review the
set -o pipefaileffect: Confirm it only controls exit code propagation, not signal propagation.Files of Interest
pkg/workflow/awf_helpers.go—BuildAWFCommand()(the pipe construction)pkg/constants/constants.go—AWFDefaultCommandconstantDockerfile— confirms no init processactions/setup/sh/stop_mcp_gateway.sh— example of correct SIGTERM handling with fallback to SIGKILL (pattern to compare against)Acceptance Criteria
Related to timeout-minutes on agent step not enforced inside AWF container #23965