Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
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.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.