Evaluating SDODS against two other tools, so forgive the basic question. A nightly ended with exit code 130 and there is no failing scenario in the report — 212 passed, 0 failed, and then 130.
Our triage rules file anything non-zero as a defect. Should this one be?
Accepted answer
No. 130 means the run was cancelled — Ctrl-C, a cancel from the server or the web UI, or the process being killed. It is not a test result, and filing it as a defect against the suite will waste somebody's morning.
In CI it is nearly always one of: the job hit its timeout, the workflow was cancelled because a newer commit superseded it, or the agent was reclaimed.
The exit code is recorded in run.json alongside finishedAt, so you can tell a cancelled run from a completed one after the fact without reading the log. The whole set is worth putting in your triage rules: 0 passed, 1 failures, 2 configuration or usage, 3 lint errors, 130 cancelled — they are all listed on Reference → Exit codes. Only 1 is a defect candidate.
Check the step timeout against the run's own duration first. If the run was still going at the cut-off, the interesting question is why it was slow, and --max-failures gives you a much earlier signal than a timeout does — a run that is going to fail 40 scenarios does not need to prove it 40 times.
Have a different question? Ask it.