0 = success. 1 = execution error (query failure, auth failure, parse error). 2 = fatal client-init error (bad URL, can't construct HTTP client).
## Overview DeltaForge's CLI uses three exit codes. Zero indicates success, one indicates that a command ran but its work did not complete successfully, and two is reserved for fatal init errors where the CLI could not even start talking to the service. The distinction between one and two is useful in CI pipelines where recoverable SQL failures should be reported differently from misconfiguration. ## Behavior - Exit 0: every command completed without returning an error. For `run`, this means every statement reported success; for `query`, the single statement returned a result; for `health`, the health checks finished (note that an unreachable control plane or compute engine is logged but does not change the exit code on its own). - Exit 1: the top-level command returned `Err(...)`. Causes include authentication failure, `--var` parse issues, HTTP errors against the compute engine, SQL parse or execution errors reported by the engine, and any statement in `run` or piped-stdin mode failing. `main` prints the error via `output::print_error` and exits. - Exit 1: also used when the interactive post-login setup fails (authentication error at startup). - Exit 2: `DeltaForgeClient::new` failed before any request was sent. This is raised in the demo-test branch when the HTTP client cannot be constructed, typically because `control_url` or `compute_url` is malformed or the reqwest builder rejected the TLS configuration. Other subcommands currently surface client-construction failures as exit 1; exit 2 is specific to the demo-test entry point. - Non-zero exits are final. The CLI never retries at the process level; retries and token refresh happen inside a single process run. ## Compatibility - Stable across `query`, `run`, piped stdin, `auth`, `health`, and `demo-test`. - `cargo run`-wrapped invocations can add their own non-zero codes for compilation failures; scripts that invoke the binary directly do not see those. - Shell integration: `$?` in bash/zsh, `$LASTEXITCODE` in PowerShell, and `%ERRORLEVEL%` in cmd.exe all read the same numeric value.
# Guard a CI step on success
delta-forge-cli query 'SELECT 1' && echo ok# Capture and branch on the specific code
delta-forge-cli run bad.sql
case $? in
0) echo success ;;
1) echo 'SQL or auth failure' ;;
2) echo 'client init failure; check control_url' ;;
*) echo "unexpected exit $?" ;;
esac# Typical CI pattern: halt the job on first error
delta-forge-cli --profile ci run nightly/etl.sql || exit $?# demo-test also uses exit 2 when the HTTP client cannot be built,
# and exit 1 when setup or queries had errors
delta-forge-cli demo-test prod-node sales demos/csv/sales-quickstart; echo $?