Bug Description
specify workflow run (and workflow resume) exit with code 0 even when the run ends Status: failed. The epilogue of workflow_run prints the status and falls through without mapping the outcome to an exit code (src/specify_cli/__init__.py:2880 area; the --json path likewise emits the payload and returns). Scripts, CI jobs, and orchestrators cannot rely on $? — they must parse stdout for Status: to learn the run failed.
Steps to Reproduce
cat > fail.yml << 'YAML'
schema_version: "1.0"
workflow:
id: fail-test
name: Fail Test
version: "1.0.0"
steps:
- id: boom
type: shell
run: "exit 1"
YAML
specify workflow run fail.yml; echo "exit=$?"Expected Behavior
Status: failed (or aborted) → process exit code 1; completed and paused → 0 (paused is a legitimate waiting state, not a failure). The --json path should carry the same code alongside the payload.
Actual Behavior
Status: failed … exit=0.
Specify CLI Version
main @ 1b0556c (also present in 0.9.2)
AI Agent
n/a (CLI behavior, agent-independent)
Operating System
macOS 14 (not OS-specific)
Python Version
3.11
Heads-up — this is a deliberate-looking behavior: tests/test_workflow_run_without_project.py::test_workflow_run_failing_yaml_without_project currently asserts exit_code == 0 on a failed run (i.e. "the CLI ran fine; the workflow outcome is data"). So this issue is effectively a behavior-change proposal: anyone scripting against exit-0-on-failed would be affected. I'd argue the script-ergonomics convention (non-zero on failure) outweighs that, but flagging it clearly. I have a small PR ready that updates the pin and adds coverage for both directions.
AI disclosure (per CONTRIBUTING.md): this issue and the accompanying PR were authored with AI assistance (Claude); all behavior was verified by running the repo's test suite locally.
Bug Description
specify workflow run(andworkflow resume) exit with code 0 even when the run endsStatus: failed. The epilogue ofworkflow_runprints the status and falls through without mapping the outcome to an exit code (src/specify_cli/__init__.py:2880area; the--jsonpath likewise emits the payload and returns). Scripts, CI jobs, and orchestrators cannot rely on$?— they must parse stdout forStatus:to learn the run failed.Steps to Reproduce
Expected Behavior
Status: failed(oraborted) → process exit code 1;completedandpaused→ 0 (paused is a legitimate waiting state, not a failure). The--jsonpath should carry the same code alongside the payload.Actual Behavior
Status: failed…exit=0.Specify CLI Version
main @ 1b0556c (also present in 0.9.2)
AI Agent
n/a (CLI behavior, agent-independent)
Operating System
macOS 14 (not OS-specific)
Python Version
3.11
Heads-up — this is a deliberate-looking behavior:
tests/test_workflow_run_without_project.py::test_workflow_run_failing_yaml_without_projectcurrently assertsexit_code == 0on a failed run (i.e. "the CLI ran fine; the workflow outcome is data"). So this issue is effectively a behavior-change proposal: anyone scripting against exit-0-on-failed would be affected. I'd argue the script-ergonomics convention (non-zero on failure) outweighs that, but flagging it clearly. I have a small PR ready that updates the pin and adds coverage for both directions.AI disclosure (per CONTRIBUTING.md): this issue and the accompanying PR were authored with AI assistance (Claude); all behavior was verified by running the repo's test suite locally.