k6-baseline workflow reports failure even on a clean run (EXIT trap masks exit code) #837

What happened

The scheduled/dispatched `k6 load-test baseline` workflow has failed its last two runs
(run 34789303742,
2026-08-08 run) even though the underlying baseline was clean both times: all reps completed,
no k6 threshold breaches, persona coverage and cast-user coverage both True.
run-baseline.sh printed:

status: clean — no flagged reps, persona coverage OK on every rep.

immediately followed by:

##[error]Process completed with exit code 1.

Root cause

tools/simulation/run-baseline.sh's EXIT trap:

trap 'kill -TERM "${sampler_pid:-}" 2>/dev/null; wait "${sampler_pid:-}" 2>/dev/null || true' EXIT

runs under the script's set -euo pipefail. By the time the trap fires at final exit, the
last rep's docker-stats-sampler was already killed and reaped by the normal per-rep cleanup
a few lines earlier, so kill -TERM "$sampler_pid" finds no such process and returns
non-zero. Because set -e is still in effect while the trap runs, that failing kill
aborts the trap immediately — wait ... || true never executes — and the trap's own exit
status (1) silently replaces the script's explicit exit "$overall_exit" (0), which had
already run.

Reproduced in isolation:

bash -c '
set -euo pipefail
trap "kill -TERM \"\${sampler_pid:-}\" 2>/dev/null; wait \"\${sampler_pid:-}\" 2>/dev/null || true" EXIT
echo "status: clean"
exit 0
'
echo "actual exit code: $?"   # prints 1, not 0

The per-rep kill a few lines above the trap already guards against exactly this
(kill -TERM "$sampler_pid" 2>/dev/null || true); the EXIT trap's copy of the same command is
missing the || true.

Fix

Add the same || true to the kill in the trap. Fixed in #TBD (opening alongside this issue).

Impact

• Every k6-baseline.yml run has been reporting failure regardless of actual baseline
  health, since at least the 2026-08-08 run — the two most recent runs are both affected.
• No masking of a real regression is known to have happened (both runs' underlying data was
  clean), but a genuinely flagged rep would also always show as exit 1 either way, so this bug
  makes the job's conclusion useless as a signal either direction until fixed.