fix(core): strip virtual fields from include before Prisma call by borisno2 · Pull Request #633 · OpenSaasAU/stack

borisno2 · 2026-07-10T01:57:56Z

Summary

Virtual fields named in a caller-supplied include (e.g. context.db.myList.findMany({ include: { myVirtualField: true } })) used to be forwarded straight through to Prisma, which threw Unknown field '<name>' for include statement because virtual fields have no database column.
Adds stripVirtualFieldsFromInclude() in packages/core/src/access/access-filter.ts, which recursively removes virtual-field keys from a Prisma include object while preserving real relationship includes (and their nested access-control filters) at every level.
Applied as the final step in context/index.ts for both findUnique and findMany, after include is resolved via the fragment path, the access-controlled merge path, or the sudo passthrough path — so a virtual key never reaches the Prisma client regardless of which path produced it.
The virtual field's value is unaffected: filterReadableFields already computes it unconditionally via resolveOutput, whether or not the field was named in include.

Test plan

Regression tests added in packages/core/tests/context.test.ts (virtual fields named in include no longer reach Prisma (#628)):
- findMany/findUnique with a virtual field alongside a real relationship in include — the virtual key is stripped from the Prisma call, the relationship include is untouched, and the virtual value is still returned.
- The virtual value is populated even when omitted from include.
- Sudo path also strips the virtual key (while leaving the real relationship passthrough unfiltered, matching existing sudo behaviour).
- Read access control on a virtual field is still enforced (a field denied by read access is omitted from the result).
pnpm test — full packages/core suite passes (729 tests)
pnpm build (tsc) passes
pnpm lint — no new warnings/errors
pnpm format / pnpm manypkg fix — no changes needed beyond the diff
Changeset added (@opensaas/stack-core: patch)

Closes #628

Virtual field keys named in `include`/`select` used to be forwarded straight through to Prisma, which threw "Unknown field" since virtual fields have no database column. The read path now strips virtual keys from the include payload (fragment, access-controlled merge, and sudo passthrough) while the value is still computed via resolveOutput regardless of whether the field was named. Closes #628 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A6fWyGeMiexwmQLD2usMcn

changeset-bot · 2026-07-10T01:58:00Z

🦋 Changeset detected

Latest commit: bb84ccc

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	Patch
@opensaas/stack-auth	Patch
@opensaas/stack-cli	Patch
@opensaas/stack-rag	Patch
@opensaas/stack-storage	Patch
@opensaas/stack-tiptap	Patch
@opensaas/stack-ui	Patch
@opensaas/stack-storage-s3	Patch
@opensaas/stack-storage-vercel	Patch

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

vercel · 2026-07-10T01:58:02Z

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

Project	Deployment	Actions	Updated (UTC)
stack-docs	Ready	Preview, Comment	Jul 10, 2026 1:58am

borisno2

Code Review

Overview

Fixes #628: a virtual field named in a caller-supplied include (e.g. context.db.myList.findMany({ include: { myVirtualField: true } })) used to be forwarded straight to Prisma and throw Unknown field at runtime, since virtual fields have no database column. This PR adds stripVirtualFieldsFromInclude() (in access-filter.ts) and applies it as the final step before model.findFirst/model.findMany in context/index.ts, covering all three paths that can produce include (fragment-built, access-controlled merge, sudo passthrough).

Correctness

Core logic is sound. The strip check (fieldConfig?.virtual) runs before the relationship check, so a virtual field is dropped regardless of whether its value is bare true or an object — matches all the ways a caller could name it.
Nested relation includes preserve non-include keys correctly. The recursive branch spreads the original value (not the narrowed entry from asEntryObject) and only overrides include, so where/orderBy/take/skip/select on a relation entry survive untouched.
findFirst is covered for free since it delegates to the fixed findMany. createGet (singleton) doesn't accept a caller include and its auto-built include only ever contains relationship keys, so it's correctly left untouched.
The sudo passthrough fix is a real, distinct improvement — previously sudo used args.include completely unfiltered, so this bug applied there too. Good that it's covered by both the fix and a dedicated test.

Test coverage

Five new regression tests in context.test.ts under virtual fields named in include no longer reach Prisma (#628):

findMany/findUnique with a virtual field + real relationship in include → virtual key stripped, relationship include intact, virtual value still returned.
Virtual value populated when omitted from include (pre-existing behavior, now guarded against regression).
Sudo path strips the virtual key while leaving the real relationship passthrough unfiltered (matches documented sudo semantics).
Read access control on a virtual field still applies.

This satisfies all the acceptance criteria from the issue's triage brief. Full suite (729 tests), tsc build, and lint all pass with no regressions.

Minor/non-blocking observations

Unresolvable related config skips nested stripping. If a declared relationship's ref can't be resolved via getRelatedListConfig (unlikely — config validation should prevent a dangling ref), the nested include under that relation is passed through without recursing. This mirrors an existing fallback pattern elsewhere in the codebase (e.g. filterReadableFields's "Related config not found, include the value as-is" branch), so it's consistent rather than a new gap.
Nested select inside a relation include entry (Prisma also supports { include: { posts: { select: {...} } } }) isn't scanned for virtual keys. Out of scope per the issue — worth a follow-up only if that usage becomes common.

Security

No concerns — this only narrows what reaches Prisma; it doesn't loosen any access control path. Field-level read access on virtual fields and relationship-level access filtering both remain intact and tested.

Verdict

Solid, minimally-scoped fix with good test coverage matching the issue's acceptance criteria. No blocking issues found. Approving.

Generated by Claude Code

github-actions · 2026-07-10T02:03:28Z