Runtime support
This page answers one question: does feature X work in my runtime, and where do Go and Rust differ? The rules for each feature live in its contract doc, not here. Update a row when a feature’s status or known differences change; see Changing a runtime behavior.
LabKit owns the native SDK behavior. Bench owns the generated assembly and the chassis wiring that exposes it. An SDK feature alone doesn’t make it a bench feature; the assembly has to wire it in, and a runtime test has to check it.
Features
✅ marks supported, ⚠️ partial, and ❌ missing. “Supported” means the
generated assembly implements the feature’s contract. “Checked by” names the
assertion in
tests/integration-go.sh and
tests/integration-rust.sh (native runs);
both scripts check it.
| Feature | Contract | Go | Rust | Known differences | Checked by |
|---|---|---|---|---|---|
| Build from scaffold | bench build | ✅ | ✅ | None | Build step in both scripts |
| HTTP endpoints | HTTP adapter contract | ✅ | ✅ | ⚠️ Body size cap ( details) | assert_json_post, plus the request-body cases the contract lists |
| Liveness probe | Chassis (LabKit) | ✅ | ✅ | None | assert_probe: GET /-/liveness returns 200 |
| Readiness probe | Chassis (LabKit) | ✅ | ✅ | None | assert_probe: GET /-/readiness returns 200. The fixture has no backends, so the not-ready state isn’t exercised |
| Metrics endpoint | Chassis (LabKit) | ⚠️ Partial: Go runtime and process metrics only, no HTTP request metrics ( bench#73) | ✅ | ⚠️ Only Rust records HTTP request metrics, such as http_server_request_duration | assert_probe: GET /-/metrics returns 200. The Rust script also checks for http_server_request_duration after requests |
| Graceful shutdown | Chassis | ✅ | ✅ | Same behavior. Go uses LabKit’s app.Run; the Rust chassis handles SIGTERM itself because labkit-rs has no lifecycle model (
bench#80) | SIGTERM step in both scripts (exit 0) |
There’s no automated completeness check, so reviewers compare rows with the
contracts and scripts. Shared assertions live in
tests/runtime-checks.sh.
In flight
These features are designed but haven’t shipped, and the runtimes take different paths while the work lands. Status and progress live in the tracking items, not here. When a feature ships, move it to the Features table.
| Feature | Design | Go | Rust | Tracking |
|---|---|---|---|---|
| Inbound authentication | Inbound authentication | Verification delegates to userauth, as Artifact Registry does | New verification code in bench (jsonwebtoken, RS256 pinned); Rust has no userauth equivalent | bench!196 adds a presence-only bearer check to both runtimes; bench#87 |
| Application config | appconfig design, in review | LabKit’s config.ResolvePath(), in review in
labkit!805 | labkit-rs’s existing labkit_config::resolve_path() | Both look in $CONFIG_DIR/config.yaml, then $CONFIG_PATH, then config/local.yaml;
bench#106 |