BUG-CLI-02/03/04: CLI always exits 0 on errors — error paths never call sys.exit(1)

[govindkavaturi-art]

Summary

Multiple CLI commands print an error message but exit with code 0 on failure. This makes the CLI unusable in scripts and CI pipelines that check return codes.

Affected Commands

Command	Error condition	Expected exit	Actual exit
cueapi create --cron "not-valid" --url ...	Invalid cron (HTTP 400)	1	0
cueapi get <nonexistent-id>	Cue not found (HTTP 404)	1	0
cueapi delete <nonexistent-id> --yes	Cue not found (HTTP 404)	1	0

Root Cause

All error paths in the CLI call echo_error() to print the message, then silently return instead of calling sys.exit(1) or using Clicks ctx.exit(1)`.

Example from the get command:

if resp.status_code == 404:
    echo_error("Cue not found")
    return  # ← should be sys.exit(1)

Fix

All error handling paths that call echo_error() should follow with a non-zero exit:

echo_error("Cue not found")
sys.exit(1)

Or use Click`s built-in:

raise click.ClickException("Cue not found")

This affects at minimum create, get, and delete — a full audit of all 14 commands is recommended.

Impact

• Scripts and CI pipelines that run cueapi and check $? will always see success even on failure
• Makes automated gating (e.g. cueapi create ... || exit 1) impossible

Severity

P1 — systemic issue affecting CI/CD usability of the CLI.