Measured while landing #12048 (PR #12339), which gives the SDK docs pages a resolution environment that can see @objectstack/client. That change is what makes this measurable at all — before it, every fence on this page red with TS2307 and nothing downstream of the import was ever reached.
⛔ Not a marker/coverage question, and deliberately not filed as part of #11942's remaining scope in that sense: this is about what the examples teach, and it is true whether or not the blocks are ever marked.
The defect
Two blocks on the page — "Error Handling" (around line 582) and "Per-field validation errors" (around line 609) — are written:
try{awaitclient.data.create('todo_task',{subject: ''});}catch(error){console.error(error.code);// 'VALIDATION_FAILED'console.error(error.httpStatus);// 400// ...}Under strict (which implies useUnknownInCatchVariables), error is unknown, so every one of those reads is TS18046: 'error' is of type 'unknown'. A reader who copies this into their own strict project — the default for tsc --init since TS 4.4, and what this repo's own packages use — does not get working code; they get a compile error, with no hint on the page that narrowing is required.
Measurement
With all 13 fences on the page temporarily marked and the gate run against the post-#12048 surface (tree reverted afterwards), these two blocks produced 10 of the 114 diagnostics:
| block | diagnostics |
|---|
582 Error Handling | 6 — 1× TS2304 client, 5× TS18046 'error' is of type 'unknown' |
609 Per-field validation errors | 4 — 1× TS2304 client, 2× TS18046, 1× TS2304 showFieldError |
The TS2304s are the page's deliberate continuation-fragment convention (Quick Start establishes client once) and are not this card. The TS18046s are not — they would fire in a reader's file too, where client is defined.
Why it is worth fixing rather than accepting
This is the page a customer opens to learn the SDK, and error handling is the part they copy most literally. The fix is also what the page should teach anyway: the SDK throws a typed error, and the example should show the reader how to reach it — a narrowing helper or type guard exported from @objectstack/client, or at minimum an instanceof / shape check in the example. Whether such a guard exists and is exported is the first thing to check; if it does not, the honest reading is that the SDK has no supported way to narrow a caught error, which is a bigger finding than the docs page.
Once the examples narrow honestly they become self-contained enough to carry an os:check marker (the remaining TS2304 client is the page's separate continuation convention), so this also converts two more fences from unverifiable to gated.
Not in scope here
Refs: #12048 / PR #12339 (the surface fix that made this measurable) · #11942 (the page's coverage card) · #8140 (the narrowing that falsified two other examples on this page)
Measured while landing #12048 (PR #12339), which gives the SDK docs pages a resolution environment that can see
@objectstack/client. That change is what makes this measurable at all — before it, every fence on this page red with TS2307 and nothing downstream of the import was ever reached.⛔ Not a marker/coverage question, and deliberately not filed as part of #11942's remaining scope in that sense: this is about what the examples teach, and it is true whether or not the blocks are ever marked.
The defect
Two blocks on the page — "Error Handling" (around line 582) and "Per-field validation errors" (around line 609) — are written:
Under
strict(which impliesuseUnknownInCatchVariables),errorisunknown, so every one of those reads isTS18046: 'error' is of type 'unknown'. A reader who copies this into their own strict project — the default fortsc --initsince TS 4.4, and what this repo's own packages use — does not get working code; they get a compile error, with no hint on the page that narrowing is required.Measurement
With all 13 fences on the page temporarily marked and the gate run against the post-#12048 surface (tree reverted afterwards), these two blocks produced 10 of the 114 diagnostics:
582Error Handlingclient, 5× TS18046'error' is of type 'unknown'609Per-field validation errorsclient, 2× TS18046, 1× TS2304showFieldErrorThe TS2304s are the page's deliberate continuation-fragment convention (Quick Start establishes
clientonce) and are not this card. The TS18046s are not — they would fire in a reader's file too, whereclientis defined.Why it is worth fixing rather than accepting
This is the page a customer opens to learn the SDK, and error handling is the part they copy most literally. The fix is also what the page should teach anyway: the SDK throws a typed error, and the example should show the reader how to reach it — a narrowing helper or type guard exported from
@objectstack/client, or at minimum aninstanceof/ shape check in the example. Whether such a guard exists and is exported is the first thing to check; if it does not, the honest reading is that the SDK has no supported way to narrow a caught error, which is a bigger finding than the docs page.Once the examples narrow honestly they become self-contained enough to carry an
os:checkmarker (the remaining TS2304clientis the page's separate continuation convention), so this also converts two more fences from unverifiable to gated.Not in scope here
client. That is a deliberate, documented convention on the page and a separate question ([finding]content/docs/api/client-sdk.mdx— the most SDK-dense page in the docs — has 13 TypeScript fences and 0os:checkmarkers, so none of them is ever compiled #11942).showFieldErrorin the second block — an illustrative UI callback, correct as prose.Refs: #12048 / PR #12339 (the surface fix that made this measurable) · #11942 (the page's coverage card) · #8140 (the narrowing that falsified two other examples on this page)