SDK and error contracts
Walkthrough: proving a checkout
Walkthrough: proving a checkout What "the four runtimes are one behaviour" looks like when you actually run it. Every output block below is a verbatim capture from this repository on a machine with node , python3 , cargo , and swift install
Walkthrough: proving a checkout
What "the four runtimes are one behaviour" looks like when you actually
run it. Every output block below is a verbatim capture from this
repository on a machine with node, python3, cargo, and swift
installed — the harness needs all four because it builds and runs all four
emitters. What each check defends is in conformance;
what the failures look like is in the runbook.
The gate
$ node ci/check.mjs
ok generated code matches the catalogue
ok schema and catalogue name the same codes
ok schema and catalogue name the same severities
ok the failure point pattern is stated once
ok every golden envelope obeys the schema
ok runtimes agree (11 case(s) + 45 vocabulary row(s), 0 failing)
all checks passed
Exit 0. Six ok lines, four checks: the first runs the generator in
--check mode, the middle four compare the catalogue against the schema
and every golden envelope against both, and the last runs the whole
conformance harness and reports its summary line. This is the one command
to run before trusting a checkout, and the one CI runs before anything
ships.
The harness, on its own
$ node tests/conformance.mjs
ok credential-refused (js, python, rust, swift)
ok throttled (js, python, rust, swift)
ok store-unreachable (js, python, rust, swift)
ok nested-refusal (js, python, rust, swift)
ok silent-skip (js, python, rust, swift)
ok unattributed (js, python, rust, swift)
ok quiet-refusal (js, python, rust, swift)
ok single-segment (js, python, rust, swift)
ok deep-segment (js, python, rust, swift)
ok salvaged-malformed (js, python, rust, swift)
ok salvaged-absent (js, python, rust, swift)
ok derived vocabulary (45 rows, js, python, rust, swift)
11 case(s) + 45 vocabulary row(s), 0 failing
Exit 0. Each ok line is one golden envelope from
tests/conformance/cases.tsv that all four runtimes emitted
byte-identically — the eleven are real failures this fleet produced while
the vocabulary lived in six copies. The derived vocabulary line is the
45 probe rows of tests/conformance/table.tsv: every code's severity,
retryability, outage flag, HTTP status, exit code, and operator summary;
the upstream-status classifications including 200 and 600; the exit-code
remap given a caller's chosen code; both trim rules across the padded,
exact-width, and no-space edge cases; and membership answers for
toString, __proto__, constructor, and friends.
The first run after a fresh clone takes as long as cargo build and
swift build take — the harness builds the Rust and Swift emitters itself
rather than reporting RUNTIME MISSING on a machine that merely has not
built yet. Warm, the whole gate runs in about two seconds.
The generator, on its own
$ node codegen/generate.mjs --check
unchanged rust/src/codes.rs
unchanged python/wisent_errors/codes.py
unchanged js/codes.mjs
unchanged swift/Sources/WisentErrors/Codes.swift
Exit 0. Four unchanged lines mean the committed generated modules are
exactly what the catalogue derives; a DRIFTED line and exit 1 mean
someone edited a generated file or the catalogue without regenerating —
what that looks like, and what to do, is in the runbook.
Reading a red run
Green is one shape; red has several, each meaning something different — a drifted generated file, a schema disagreeing with the catalogue, a runtime emitting different bytes, a toolchain missing from the machine. The runbook captures each one for real, by breaking a scratch copy of this repository and pasting what the gate said.