A bash deploy script calls `run_migration`, then finishes with `echo "migration done"`, and the CI job reports success even when the migration fails. Why does the script exit 0, and how do you make it report the real status?

## The rule that causes it A bash script's own exit status is: - the argument to `exit`, if the script calls `exit N`; or - the status of the **last command executed**, if the script simply runs off the end; and - a bare `exit` with no argument is defined as `exit $?` — the status of whatever ran immediately before it. So the last thing your script does is what the outside world sees. If that last thing is a friendly progress message, the outside world sees success. ```bash #!/usr/bin/env bash run_migration # returns 1 echo "migration done" # returns 0 # script ends here -> exit status 0 ``` The symptom is a CI job that is permanently green, a cron job that never mails a failure, a container that a scheduler considers to have completed cleanly. It is one of the most consequential shell bugs precisely because nothing looks wrong: the log even contains the migration's error output, but the number that the platform gates on says success. ## Where it hides The pattern shows up in several disguises: - **A trailing summary line.** `echo "finished at $(date)"` at the bottom of every script is a house style in many teams and silently masks the status. - **A bare `exit` after a cleanup step.** `cleanup; exit` propagates `cleanup`'s status, not the work's. - **A final conditional.** If a script ends with `if [ -n "$notify" ]; then send_mail; fi` and the condition is false, the `if` produces `0` — a false branch is not a failure — and that becomes the script's status. - **A loop or a redirect at the end.** Any last construct produces a status of its own. ## The fixes, in order of preference **1. Fail at the point of failure.** The best scripts never reach the end in a broken state: ```bash run_migration || { echo "migration failed" >&2; exit 1; } echo "migration done" ``` or equivalently with a conditional: ```bash if ! run_migration; then echo "migration failed" >&2 exit 1 fi ``` Now the trailing `echo` is only ever reached on the success path, so it cannot mask anything. **2. Capture and propagate.** When you must run something after the failure — a report, an upload of logs — save the status before anything else executes: ```bash run_migration rc=$? upload_logs echo "migration finished (status $rc)" exit "$rc" ``` The capture must be the *immediately* following line; anything in between overwrites the value, which is the same one-shot property that makes `$?` easy to misuse. **3. Preserve the distinction you care about.** If a caller branches on specific codes, propagate the original number rather than collapsing everything to `1`. `exit "$rc"` keeps a tool's own `2` or `3`; `exit 1` throws that information away. Conversely, if you want a stable contract, map the codes deliberately and document the mapping. ## Related traps in the same family A cleanup handler registered to run on exit can also overwrite the status if its last command succeeds — the standard guard is to capture the status at the top of the handler and re-exit with it; the mechanics of registering such a handler belong with signals and traps. Bash's automatic abort-on-error setting is a separate lever with its own well-known blind spots, covered under strict mode and error handling; note only that it does not save you here, because the trailing `echo` genuinely succeeds and there is nothing for it to abort on. ## How to catch it in review Read the bottom of every script and ask: *what is the last command on the success path, and on each failure path?* If the answer on any failure path is a log line, the script lies to its caller. A quick empirical check is worth more than reasoning: ```bash ./deploy.sh; echo "exit status: $?" ``` Run it once with the real work forced to fail. If it still prints `0`, you have found the bug. Making that check part of how you accept a new operational script is cheap and catches the whole class. ## What to say in an interview "The script exits with the status of its last command, which is the `echo`. I'd either fail fast with `run_migration || exit 1`, or capture `rc=$?` on the next line and end with `exit "$rc"` — and I'd verify by running the script with the step forced to fail and printing `$?`."