Four Layers, One Status Code: Testing Tenant Scope on a Generated Prisma Route

A dev.to walkthrough builds a single generated Prisma read endpoint and then breaks it five ways on purpose, with each break landing in exactly one of four places: shape construction, request validation, emitted Prisma arguments, or execution-time projection ^[1]. The operational point arrives in the first paragraph and is worth more than the code: the status code alone is not enough to identify which layer moved ^[2].

The setup is deliberately small. `Nursery` is annotated as the scope root and `Plant` carries the `nurseryId` foreign key that the guard extension can constrain ^[5]. Authentication stays in application code, and the tenant ID is read from the authenticated session rather than from the query string or body ^[6][7]. That is the boundary most multi-tenant bugs cross, and it is invisible in a response body.

The contract itself is a shape, where `true` means the client may choose a value and a literal means the server chose it; because bare `true` is already the permission sentinel, pinning a Boolean requires `force(true)` ^[8]. The public read shape allows a case-insensitive `contains` on name, forces `isPublished` to true, selects three fields, permits sorting on two, and sets `take` to a maximum of 50 with a default of 20 ^[9]. So a caller that sends no `take` receives 20 rows and cannot page past 50 no matter what it asks for ^[21]. The router picks the public variant server-side, so a client cannot promote itself by inventing a variant header ^[11].

Tenant scope is a separate layer from that public shape ^[12]. The extension injects a mapped top-level foreign key when trusted root context exists, but the root model does not scope itself and nested relation reads do not inherit the filter ^[12]. That is the failure mode that returns 200 with rows from someone else's nursery, which is why the author keeps the authenticated-context test separate from the forced-publication test: a single combined test tells you something broke, not which boundary ^[13].

The break diagnostics are the useful part. Writing `isPublished: force(true)` inside `where` looks like correct mutation syntax but fails at shape construction with `Operator "value" not supported for type "Boolean"`, before any client input is examined; the fix is `{ equals: force(true) }`, because a `where` shape forces an operator while a `data` shape forces the field itself ^[14][15]. That class of fault is a startup or first-use configuration defect and retrying the request cannot repair it ^[16]. The triage rule follows: if the same error appears with an empty body and for every caller, reduce the shape before investigating transport encoding, whereas a path such as `where.name` in an invalid-query message points at the client-facing schema that rejected input ^[17][18]. Strictness is also directional. Because the shape fixes `mode` beside `contains`, a frontend that sends `mode: "insensitive"` is rejected for sending the key at all, even with the identical value ^[19].

Versions are pinned at prisma-guard 1.33.0, Prisma 6.19.3 and Zod 4.4.3 precisely because several of these observations depend on exact runtime behavior, and the stated goal is a test you rerun during upgrades rather than a rule inferred from one successful response ^[3][4]. The available text details two of the five breaks and cuts off mid-sentence ^[20], so treat the other three as unverified.

Watch what happens to these assertions on the next minor bump of either the generator or Zod: strict-key rejection and operator-type errors are exactly the behaviors that drift quietly, and the four-layer split is what makes that drift attributable.