🐞 dagger call non-zero exit code silently swallowed by process substitution in exec step

[moltar]

What is the issue?

When dagger call fails with a non-zero exit code, the GitHub Actions step still reports success. The Dagger CLI correctly outputs error markers (✘, ERROR, exit code: 1), but the step exits 0.

Root cause

The exec step in action.yml redirects stdout/stderr through bash process substitutions:

cd $WORKDIR && { \
  dagger call ...; } 1> >(tee "${tmpout}") 2> >(tee "${tmperr}" >&2)

Bash's set -e (which GitHub Actions enables by default for shell: bash) does not detect non-zero exit codes from commands whose output is redirected through process substitutions (>(...)). This is a well-documented bash behavior.

You can reproduce this with a minimal script:

#!/usr/bin/env bash
set -e -o pipefail

# This SHOULD abort the script, but doesn't:
false 1> >(tee /dev/null) 2> >(tee /dev/null >&2)

echo "BUG: still running after 'false' — exit code was swallowed"

Because the dagger exit code is silently ignored, the script continues to the summary generation code that follows, which succeeds. The step's overall exit code becomes 0.

Affected versions

Verified on commit 662d9b66 and the latest v8.4.0 — the pattern is identical in both.

Suggested fix

Capture the exit code explicitly before continuing to summary generation:

tmpout=$(mktemp)
tmperr=$(mktemp)

# Run dagger and capture exit code
set +e
cd $WORKDIR && { \
  dagger call ...; } 1> >(tee "${tmpout}") 2> >(tee "${tmperr}" >&2)
dagger_exit=$?
set -e

# ... summary generation (runs regardless) ...

# Propagate the original exit code
exit $dagger_exit

Alternatively, switch from process substitution to pipes, which work correctly with set -o pipefail:

cd $WORKDIR && dagger call ... 2>&1 | tee "${tmpout}"
# With pipefail, this correctly propagates dagger's exit code