The opaque wrapper with all() and first(): operation access, the Access Filter as a filter entry, Silent failure by borisno2 · Pull Request #1216 · OpenSaasAU/stack

borisno2 · 2026-09-06T11:44:41Z

Implements #1146
Part of #1123

What this lands

context.db.<List> is now spelled the way the config spells the list — context.db.AuthUser, never context.db.authUser — and it is an opaque wrapper over a Prisma 8 collection: .where(...) composes an immutable value, and .all() / .first() are the engine-owned terminals that run it.

A terminal, in one place (packages/core/src/secured/read.ts):

resolves operation-level query access lazily (sudo skips it),
runs the predicate-time key and read-access checks (Read path forwards undeclared where / orderBy keys straight to Prisma #912/A field read gate withholds the value but not the predicate — every gated column is a filter oracle #915) — only once the caller is known to have some access to the list, so the error messages are not an oracle,
lowers the caller's predicates and the Access Filter each to one entry in the collection's own filter list — .where(caller).where(accessFilter), which rc.8 ANDs natively. Nothing is hand-merged; mergeFilters is not on this path,
enters the engine origin around the ORM call and materialises (ADR-0046),
applies Field Visibility per row,
returns [] / null on denial — Silent failure, indistinguishable from an empty result, and the database is never reached.

getDbKey is deleted (getUrlKey / getListKeyFromUrl stay). The engine's ORM handle, ormModel, context.db, the MCP handler, nav counts, the fragment runner, the RAG storages and the auth plugin all key by the list name now, as does the generated DB interface (packages/cli/src/generator/types.ts), which is where context.db.authUser becomes a compile error — Property 'authUser' does not exist on type 'DB'. Did you mean 'AuthUser'? is exactly what the CLI's type-fixture tests now report for the old spelling.

The delegate-name / short-circuit problem

Spec 3's QA gate (on #1123) recorded two failure modes: the engine called Prisma 7 delegate names (findMany and siblings) against rc.8 collections, which expose where/all/first/create; and without sudo a call returned [] / null because deny-by-default short-circuits before the database — so a test could be green while touching nothing.

The read path now calls the rc.8 names. The terminals drive collection.where(...)/all()/first() directly, so context.db.<List>.all() is a real round-trip against the harness's Postgres.
The write path is untouched and explicitly owned elsewhere. create/update/delete/count/findMany and the fragment reads still carry the Prisma 7 delegate names; writes are spec 4 (Spec: The secured surface, writes — connect, transactions, the row lock and stack-owned errors #1124) and the remaining read shapes are The Where vocabulary and its lowering; the filter module retyped #1147–The nearest() terminal over a native vector column #1151. Nothing here silently leaves the read path broken — the terminals are the read path.
The round-trip test (packages/core/src/secured/read.test.ts) seeds a row through the Unsafe origin (the harness's own collection, not the engine — the write path is not this ticket's) and reads it back through context.db.Post.all(), asserting on the row's id and createdAt: values the database minted, which a short-circuited read cannot produce.
The negative control seeds the same way into a list that declares no query rule (deny-by-default), reads it through the identical call, and asserts both that the result is [] and that the positive test's own assertion fails against it (expect(() => expect(rows[0]).toMatchObject(...)).toThrow()). A sibling test asserts the recorder saw no plan at all for that read — the denial short-circuits before the database, and the round-trip assertion is provably falsifiable by it.

Test coverage, by `CONTEXT.md` term

Everything is asserted through createTestContext and the recording middleware — never on wrapper internals.

Silent failure — anonymous / author / other-user sessions over a blog fixture each get exactly their rows; a denied list returns [] and null, equal to a genuinely empty list's; a denied read compiles no plan.
Access Filter — the recorded AST's where is { kind: 'and', exprs: [caller, accessFilter] }; with no caller predicate it carries the access filter alone; under sudo it carries the caller's predicate alone.
Field Visibility — a read-denied field is absent from the row, and a predicate naming it (or a column the list does not declare) is refused.
Engine origin — both terminals compile their plans under origin: 'engine', with the tripwire installed in its only (throwing) mode.
Opacity — a composed query's own keys are exactly where/all/first, and state/ctx/modelName/registry/tableName are all undefined on it.
Immutability — narrowing a query leaves the query it was narrowed from unchanged.
PascalCase keying — context.db.Post works, context.db.post is undefined, Object.keys(context.db) is the list names, and getDbKey is gone from the package entry.

Design notes

Why an equality-only predicate. where takes { column: value } or { column: { equals: value } }, and lowerPredicate throws UnsupportedPredicateError naming the list and column for anything else — a predicate can only ever narrow, so an operator the engine cannot lower is refused rather than dropped. The closed Where vocabulary (in, not, the comparisons, contains, AND/OR/NOT, some/every/none) is The Where vocabulary and its lowering; the filter module retyped #1147, and lowerPredicate is the single seam it replaces. The type layer mirrors the runtime: ListPredicate on the generated SecuredList accepts equality only, so { title: { contains: … } } is a compile error today as well as a runtime refusal.
Why the Access Filter is a second .where() call. rc.8 documents repeated where as AND-combined and emits them as sibling entries under one and node — which is what makes "the access filter is a filter entry, not a merge" a checkable fact about the plan rather than a claim about our code.
MCP tool names are unchanged. The handler keys context.db by the list name but still spells its tool names list_post_query via pascalToCamel — the tool name is an identifier assistants have already bound to, and renaming it is not this ticket's to do.
The legacy delegate members stay on the wrapper for now (findMany, create, …), so the admin UI, MCP and RAG keep compiling while specs 4 and 7 convert them. They expose no Collection and no CollectionState; the acceptance criterion is about what is reachable, and nothing here hands one out.

Verification

Run in this worktree, all green:

pnpm lint — 0 errors (2 pre-existing warnings, untouched)
pnpm format:check — clean; pnpm manypkg fix — no changes needed
turbo run build --filter='./packages/*' — 10/10
turbo run test --filter='./packages/*' — core 1545 passed / 1 skipped, ui 611, cli 332, auth 298 (+4 skipped), rag 362, storage 197, storage-s3 43, storage-vercel 56, create-opensaas-app 42 (+2 skipped)
The contract fixture regenerates byte-identical (opensaas generate leaves it clean), as CI requires.

🤖 Generated with Claude Code

… all()/first() `context.db.<List>` is keyed by the config's own spelling of the list name and `getDbKey` is deleted; every call site through the secured surface, and every ORM handle the engine reaches a model through, moves to the list key. The same member is now a query value. `.where(...)` composes an immutable read; `.all()` and `.first()` are engine-owned terminals that resolve operation-level `query` access lazily, add the Access Filter as a second entry in the collection's own filter list, enter the engine origin around the ORM call, apply Field Visibility and materialise — returning `[]`/`null` on denial. The terminals call the rc.8 collection method names (`where`/`all`/`first`), so the read path reaches a real database through `createTestContext`. The Prisma 7 delegate names on the write path are untouched and stay #1124's. Implements #1146 Part of #1123 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

chatgpt-codex-connector · 2026-09-06T11:44:45Z

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

vercel · 2026-09-06T11:44:46Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
stack-docs	Ready	Preview	Sep 6, 2026 12:09pm UTC

changeset-bot · 2026-09-06T11:44:48Z

🦋 Changeset detected

Latest commit: 193bfed

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@opensaas/stack-core	Minor
@opensaas/stack-auth	Minor
@opensaas/stack-cli	Minor
@opensaas/stack-rag	Minor
@opensaas/stack-ui	Minor
@opensaas/stack-storage	Minor
@opensaas/stack-tiptap	Minor
@opensaas/stack-storage-s3	Minor
@opensaas/stack-storage-vercel	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

github-actions · 2026-09-06T11:51:05Z