## Summary When `FF_ENABLE_BASH_EXIT_CODE_CHECK` is enabled, the per-command exit-code check emitted after every user script line aborts the job at the top of an `else` branch, and after a trailing `! cmd`, whenever the script is authored as separate `script:` list items. This is the same *shape* of bug as #39610, but a **different mechanism** and a **different code path**. #39610 was about a pre-command `(exit $_runner_exit_code)` status-restore that was emitted unconditionally in the `FF_CONCRETE` generator; that has been removed (!6970). This issue is about the **post-command** check, which is gated on `FF_ENABLE_BASH_EXIT_CODE_CHECK` and affects **both** the concrete and the legacy generators. The flag defaults to `false`, which is why this is not currently causing widespread breakage. ## Root cause The emitted check is: ```sh _runner_exit_code=$?; if [ $_runner_exit_code -ne 0 ]; then exit $_runner_exit_code; fi ``` It is appended after *every* user script line, including a line that is just the keyword `else`. Because the generators concatenate per-line output into one flat script with no awareness of shell block structure, the check for the `else` line lands as the **first statement inside the else branch**, where `$?` still carries the failed `if`-condition's status. So it reads a non-zero status that has nothing to do with any user command, and exits. Generated shape (else branch taken): ```sh echo "$ else" else _runner_exit_code=$?; if [ $_runner_exit_code -ne 0 ]; then exit $_runner_exit_code; fi # <- $? = 1, aborts echo "$ echo ELSE_RAN" echo ELSE_RAN ``` A trailing `! cmd` fails the same way: the negation leaves `$?` non-zero, and the check that follows it re-raises that as an exit. Note that `set -o errexit` alone does *not* cause this — the shell exempts condition contexts. It is the injected literal `if [ … ]; then exit …; fi` that is not exempt. ## Affected paths All three bash script generators emit a per-user-script-line check and are affected: 1. **Concrete** — `functions/concrete/run/stages/internal/scriptwriter/scriptwriter.go` (`buildBashScript`, `checkErr` built at ~:66-69, appended at ~:98 and ~:108). 2. **Legacy shells** — `shells/bash.go` `BashWriter.CheckForErrors()` (~:142-148), driven per script list item by `shells/abstract.go` `writeCommands` (~:1372-1402), which `defer`s `w.CheckForErrors()` inside a per-element closure. `shells/abstract_test.go` `TestWriteUserScript` pins the per-line behaviour with `CheckForErrors` `.Times(3)` for 3 script lines. 3. **`script_legacy`** — `functions/script_legacy/internal/command_processor.go` `writeNormalCommand` (~:49-61), same shape. Because all three share the defect, this is *not* a concrete-vs-legacy divergence — behaviour is consistent, and consistently wrong. ## Steps to reproduce `.gitlab-ci.yml` with `FF_ENABLE_BASH_EXIT_CODE_CHECK: "true"` and: ```yaml script: - 'if [ "$TAKE_THEN" = "true" ]; then' - 'echo THEN_RAN' - 'else' - 'echo ELSE_RAN' - 'fi' - 'echo AFTER_FI' ``` `ELSE_RAN` and `AFTER_FI` never print; the job fails with exit code 1. Minimal shell reproduction of the emitted pattern: ```sh bash -c 'set -o errexit if [ "$X" = "true" ]; then _runner_exit_code=$?; if [ $_runner_exit_code -ne 0 ]; then exit $_runner_exit_code; fi echo THEN else _runner_exit_code=$?; if [ $_runner_exit_code -ne 0 ]; then exit $_runner_exit_code; fi echo ELSE fi echo AFTER' ``` ## Existing test coverage `functions/concrete/run/stages/internal/scriptwriter/scriptwriter_test.go` has two subtests in `TestBashScript_Execute` that reproduce this and are currently `t.Skip`-ed with a reason pointing here: - `else branch runs to completion with exit code check` - `negated command does not abort the script with exit code check` Removing the skip guard makes exactly those two fail. They should be un-skipped as part of fixing this. ## Impact Any job that enables `FF_ENABLE_BASH_EXIT_CODE_CHECK` and whose `script:` contains an `if`/`else` (with the else branch taken) or a trailing `! cmd`, authored as separate list items, aborts silently — the log shows the echoed `$ …` header for the branch body and then the failure, with the command never having run. Mitigated by the flag defaulting to off. ## Possible approaches The check needs to not fire on a status that no user command produced. Options include only emitting it after lines that can actually be a complete command (skipping bare block keywords such as `else`, `elif …; then`, `do`, `then`, `fi`, `done`), or restructuring so the check is attached to logical commands rather than physical script lines. Whatever is chosen should be applied to all three generators together so they do not diverge. ## Open sub-question: pwsh `buildPwshScript` appends its own post-command check `if(!$?) { Exit &{if($LASTEXITCODE) {$LASTEXITCODE} else {1}} }` after every line, **unconditionally** (not gated on the exit-code-check flag, unlike bash). For an `if (cond) {` / … / `} else {` / … / `}` script authored as separate list items, that check lands as the first statement inside the else block — structurally the same position as the bash trap. Reasoning about pwsh semantics suggests it is harmless (`$?` after evaluating a false `if` condition should be `$true`, so the guard would not fire), but **this has not been executed or verified**, and `TestPwshScript` only ever passes self-contained single lines — there is no pwsh equivalent of `TestBashScript_Execute`. Worth confirming empirically rather than assuming.