Exit codes

Orchestrators decide from a command’s exit code whether to retry a job, alert someone or stop. Every dre command uses the same codes:

Code	Meaning	What to do
0	Everything succeeded. Skipped outputs (when: false, a {deliver: false} destination) count as success.	Nothing.
1	The command ran, but something failed: a report or a delivery (details per Binding in run_results.json), or problems dre validate found.	Look at the failures. A retry may help when the cause was temporary (a connection, the warehouse).
2	The command couldn’t start: bad flags or environment, an invalid project or profile, an unknown selection, a missing plugin. Nothing ran.	Fix the cause; retrying won’t help.
124	The run took longer than its timeout (--timeout, DRE_RUN_TIMEOUT, flags: run_timeout); the running Binding is recorded as timed_out.	Raise the timeout, or look at what was running.
130	Cancelled by Ctrl-C (SIGINT); the running Binding is recorded as cancelled.
143	Cancelled by a termination signal (SIGTERM; on Windows Ctrl-Break, closing the console, logging off or shutting down), as an orchestrator sends when it cancels a job.

There’s no separate code for a run where some reports failed and others delivered: 1 means something failed, and each Binding’s run_results.json says which.

For dre validate, dre compile, dre deps and dre ls, 1 means the command ran and found problems and 2 means it couldn’t run (no project, bad flags). Warnings exit 0; dre validate --strict treats them as errors, so they exit 1.

Each problem DRE reports also has an error code, whose kind says the same in more detail: a usage, config, plugin or refusal problem stops a command from starting (2), and a connection, authentication, query or delivery problem during a run makes it fail (1).

Before 0.4, dre run exited 1 for an invalid project as well as for a failed report; it now exits 2 for the first.

Preserve the process status in a job

The complete orchestration recipe records the process status rather than guessing from a message. For a minimal shell wrapper around the tutorial project:

cd examples/tutorial || exit 2
dre run --preview 5
status=$?
case "$status" in
  0) echo "Report completed" ;;
  1) echo "Inspect the run's result before deciding to retry" ;;
  2) echo "Fix configuration before retrying" ;;
  124|130|143) echo "Run stopped; inspect its recorded status" ;;
esac
exit "$status"

Capture $? immediately; another command overwrites it. A pipeline into tee can report tee’s success instead of DRE’s failure unless the shell uses pipefail. An exit code of 1 does not prove retrying is safe: some destinations may already have received files. Use error codes and per-Binding run results to inspect the failed step.