Troubleshooting a red Bobcat specification New in 1.16.0
Diagnose a red Bobcat specification from what the run wrote out, without rerunning under a debugger: every gathered disagreement on the failing step, the scenario reports WolverineFx.Bobcat records on failure (Message activity, Events appended, HTTP exchanges), step logs and attachments, and the caps on each. Covers reading a failure as JSON (bobcat run --json, --results, BOBCAT_RESULTS, bobcat results-schema), asking a running bobcat ui (failing-tests, failing-spec --uid, await-run, export-run), rerunning only what was red (bobcat run --failed, --repeat, bobcat watch), making a passing run verbose, why a run button in bobcat ui or Stoat did nothing (the resident runner's busy / unknown-spec / unsupported-mode refusals, from before the last rebuild), and adding telemetry to your own vocabulary (SpecLog.Write, SpecReport.For<T> over TableReport, SpecAttachment, IFailureCapture) with the one rule every producer must follow: write from the test's async context, never from the system's own threads.
Use when a Bobcat spec is red and the assertion message is not enough, when a report or log you expected is missing, when output is being truncated, or when adding failure telemetry to a spec suite.
Skill details
- Skill name:
critterstack-sdd-bobcat-troubleshooting - Applies to:
wolverine,marten,polecat,fisher - Tags:
sdd,bobcat,troubleshooting,telemetry,debugging,agents,results-file,spec-log,spec-report,attachments,bobcat-ui - Added in: 1.16.0
- License: Proprietary. Copyright JasperFx Software LLC.