0.33.0: reads inside `resolveOutput` recurse without bound — server OOMs on any access-scoped read

[borisno2]

0.33.0: reads inside resolveOutput recurse without bound — server OOMs on any access-scoped read

Regression in 0.33.0 (works on 0.32.0). Introduced by #838 / ADR-0022 (fix for #830).

Upgrading @opensaas/stack-core 0.32.0 → 0.33.0 makes every authenticated page in our app hang and drives the Next.js server to the V8 heap limit. In CI our Playwright server died ~3 minutes into the run:

[2815:0x1ee51000] 185775 ms: Mark-Compact 4073.9 (4105.2) -> 4062.2 (4106.0) MB, pooled: 0 MB,
                            769.07 / 0.01 ms (average mu = 0.304, current mu = 0.237) task;
                            scavenge might not succeed
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x74eae8 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [next-server (v16.2.10)]

59 of 71 e2e tests failed, almost all as ERR_CONNECTION_REFUSED after the process was gone.

Cause

Two changes in #838 interact:

1. access/access-filter.ts — buildIncludeWithAccessControl

0.32 bailed out entirely inside a resolveOutput context:

if (args.context._resolveOutputCounter.depth > 0) {
  return undefined   // no auto-include: the read fetched scalar columns only
}

0.33 replaced that with a flag that still emits a one-level include for every readable relation (access-filter.ts:126):

const insideResolveOutput = args.context._resolveOutputCounter.depth > 0
// …
if (!insideResolveOutput && !visitedLists.includes(relatedListName)) {
  nested = await buildIncludeWithAccessControl(/* … */)
}
include[fieldName] = { where, nested }   // ← relation is included either way

2. access/field-visibility.ts — filterReadableFields

The depth < MAX_DEPTH guard on the relationship recursion was removed, so every returned relation row now runs its own resolveOutput hooks at any depth.

Why the guards don't hold

_resolveOutputCounter.depth is only ever read as a boolean — it is incremented/decremented in filterReadableFields but never compared against a cap. So it flags "am I inside a hook?" and never bounds how deep the nesting goes.

The two code comments justifying the change each rely on an assumption that the other change invalidates:

access-filter.ts: "no recursive call is made, so a self-referential relation terminates after one level regardless of cycles"

True of buildIncludeWithAccessControl's own recursion — but the loop doesn't run through it. It runs through the hook↔read cycle: the fetched relation rows re-enter filterReadableFields, which executes their resolveOutput hooks, each of which issues a brand-new top-level read that builds a fresh one-level include. Every turn of that cycle is a new query and a new row set.

field-visibility.ts: "by the time a result reaches this function it is already a finite, acyclic tree whose depth was decided at the pre-query phase"

True for the tree produced by one query. But the resolveOutput hooks executed during the walk issue new queries producing new trees, so the total depth is not bounded by the pre-query phase.

On a cyclic readable-relationship graph the cycle never closes, and each turn allocates another row set.

Minimal reproduction

Sketch, reduced from the real failure — I confirmed the mechanism against our app (see below), not against this exact schema in the stack test suite.

User: list({
  fields: {
    accounts: relationship({ ref: 'Account.user', many: true }),
    name: virtual({
      type: 'string',
      hooks: {
        resolveOutput: async ({ item, context }) => {
          const [a] = await context.db.account.findMany({ where: { userId: item.id }, take: 1 })
          return `${a?.firstName}`
        },
      },
    }),
  },
}),
Account: list({
  fields: {
    firstName: text(),
    user: relationship({ ref: 'User.accounts' }),
    students: relationship({ ref: 'Student.account', many: true }),
  },
}),
Student: list({
  fields: {
    account: relationship({ ref: 'Account.students' }),
    label: virtual({
      type: 'string',
      hooks: {
        resolveOutput: async ({ item, context }) => {
          const a = await context.db.account.findUnique({ where: { id: item.accountId } })
          return `${a?.firstName}`
        },
      },
    }),
  },
}),

Then, on an access-scoped (non-sudo) context:

await context.db.user.findMany({})

Trace:

1. user.findMany auto-includes to depth 5 → returns users with accounts → students.
2. filterReadableFields walks the rows and runs User.name → account.findMany. Now insideResolveOutput, so that read returns the Account plus user and students.
3. Those Student rows are walked (no depth cap now) → Student.label → account.findUnique → again returns Account + user + students.
4. → step 3, forever.

Sudo contexts are unaffected — context/index.ts uses the caller's include as-is and builds no auto-include.

Evidence

Measured on a real app (~40 lists, cyclic relationship graph), Next 16.2.10, in-process PGlite:

stack-core	GET /dashboard (one request)
0.33.0, stock	never returns; RSS 835 MB → 1.5 GB → 3.2 GB → 4.4 GB, still 290% CPU after the client disconnects
0.33.0 + one-line patch below	200 in 5 s; steady state 1.8 s, memory flat
0.32.0	unaffected — same suite, 70/70 e2e green

The patch, applied to node_modules purely to isolate the cause (restores the 0.32 behaviour):

const insideResolveOutput = args.context._resolveOutputCounter.depth > 0
if (insideResolveOutput) return { kind: 'nothing-to-scope' }   // ← added

Workaround for consumers

Pass an explicit empty include on every read issued inside a resolveOutput hook:

await context.db.account.findMany({ where: { userId: item.id }, take: 1, include: {} })

mergeIncludeWithAccessControl only walks caller-named keys, so {} fetches scalars and nothing else, and the chain terminates. Verified against stock 0.33.0.

This is per-call-site, though — one unguarded read inside a resolveOutput anywhere in the app brings the runaway back.

Suggested fix

The #830 goal (row-scope a relation read from inside a hook rather than skipping scoping) seems compatible with terminating, if the recursion is bounded somewhere it can actually see the hook↔read cycle. Options, roughly in order of how surgical they are:

1. Use _resolveOutputCounter.depth as a real cap rather than a boolean — refuse to auto-include (or to run nested resolveOutput hooks) past depth 1.
2. Don't run resolveOutput hooks on rows fetched inside a resolveOutput context — scope and return them, but don't recurse into their virtuals.
3. Keep filterReadableFields's recursion bounded by a cap tied to the cumulative hook depth, not per-query depth.

Happy to test a patch against our suite — it reproduces reliably and fails within seconds.

Versions

• @opensaas/stack-core 0.33.0 (also stack-auth / stack-ui / stack-storage 0.33.0)
• next 16.2.10, react 19.2.4, @prisma/client 7.9.1, Node 24

[borisno2]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: Bound the resolve chain so resolveOutput hooks that issue reads cannot recurse forever, and carry that chain per hook invocation instead of on a mutable counter shared by the whole request.

Verification

Reproduced against main at the 0.33.0 release commit, with a mock Prisma client that honours include:

• The reporter's schema (User → Account → Student, two virtual resolveOutput fields) on a single access-scoped findMany blew a 300-query budget and was still growing. Trace matches the reported mechanism exactly: Field Visibility → hook → new top-level read → one-level auto-include → rows walked → hook → …
• The cycle is not include-driven. Two lists with no relationship fields whatsoever, whose virtual hooks simply read each other, also recurse without bound. That shape loops on 0.32.0 too. So the unbounded chain predates 0.33.0; what fix(core): fail closed when the Access Filter can't scope a read past its depth cap #838 changed is only how easily an ordinary schema reaches it. Any include-side bound fixes the reported repro and leaves the general loop intact.
• The reporter's isolation patch is not a viable fix. It terminates, but it fails the four Access control fails OPEN past include depth 5: caller includes pass through unscoped and nested rows skip field-read filtering #830 regression tests — it is a straight revert of the first-hop scoping fix, i.e. it trades a hang for a silent unscoped read.
• The "inside a hook" signal is racy. The counter is one mutable object shared across concurrently-filtered rows. Three sibling hooks on one read observe depth 3, 2, 1, not 1, 1, 1. Worse, a plain top-level read that merely runs concurrently with an unrelated hook sees "inside a hook" and silently collapses its auto-include — measured as {"posts":{"include":{"author":true,"comments":{…}}}} degrading to {"posts":true}. That is a second, independent defect present on both 0.32 and 0.33, folded into this fix because it has the same root cause.

Design (settled — see ADR-0023)

CONTEXT.md and the ADRs are already written and committed on branch claude/triage-844-ww8xmb: ADR-0023 records the decision, ADR-0022's now-false "loop prevention is unaffected" claim is struck through and corrected, and CONTEXT.md gains Resolve chain as the domain term. Base your work on that branch rather than rewriting those files; update them only if implementation forces a genuine divergence from the recorded decision.

Current behavior

A resolveOutput hook may issue a read whose returned rows run their own resolveOutput hooks, which may read again, with no bound anywhere. The only guard is a boolean test of a shared mutable counter, which suppresses auto-include expansion inside a hook but never stops hooks from running, and is inaccurate under concurrency.

Desired behavior

• The post-query phase carries a resolve chain: an ordered collection of (listKey, fieldKey) pairs, extended per hook invocation and passed to the hook on a derived context. A top-level read starts with an empty chain. Two hooks running concurrently never observe each other's chain.
• A repeated pair throws. Refusing to re-enter a hook already on the chain is a loud, dedicated error naming the full chain (e.g. User.name → Student.label → User.name). This is deliberately not a Silent failure: a repeated pair never terminated, so no working application can depend on it, and it leaks nothing about rows. Same category as AccessScopeDepthExceededError.
• Exceeding the length cap warns. The cap is a cost limit, not a correctness guard, and can be reached by an acyclic chain that works today — so it omits the field and emits a single console.warn naming the field and chain. It must never throw.
• The include-side "inside a resolveOutput context" test is derived from the chain being non-empty, which makes it accurate under concurrency.
• Row/relation scoping inside hooks is unchanged: relations read inside a hook still carry their access where and still do not auto-expand.

Key interfaces

• AccessContext's _resolveOutputCounter: { depth: number } is replaced (not deprecated alongside) by a chain field such as _resolveOutputChain: readonly { listKey: string; fieldKey: string }[]. The two are not the same quantity, so no bridge value is honest. It is underscore-prefixed internal plumbing but sits on a publicly exported type, so hand-built context mocks across the monorepo need a mechanical, compiler-guided update.
• The transaction-rebinding context builder must carry the chain through unchanged, as it does for the counter today.
• A new error type alongside AccessScopeDepthExceededError. Do not reuse ValidationError — ADR-0022 records why.
• A new named constant beside READ_INCLUDE_MAX_DEPTH, documented explicitly as a cost limit and not an access-control boundary.

Acceptance criteria

• The reporter's 3-list cyclic schema, read once via an access-scoped findMany, terminates within a bounded query budget (regression test)
• Two lists with no relationship fields whose virtual hooks read each other throw the cycle error rather than recursing (regression test)
• The cycle error names every (list, field) pair on the chain in order, including the repeat
• An acyclic chain longer than the cost cap omits the field and warns once — it does not throw
• A top-level read running concurrently with an unrelated in-flight hook still receives its full nested auto-include (fails today)
• Sibling hooks on one read each observe a chain of length 1
• The four existing Access control fails OPEN past include depth 5: caller includes pass through unscoped and nested rows skip field-read filtering #830 regression tests pass unmodified; hook-issued reads still carry relation access wheres
• No _resolveOutputCounter remains anywhere, including test mocks
• The stale code comments asserting that the include-side guard prevents infinite loops are corrected to match ADR-0023
• A minor changeset via the pr-changeset skill, covering the AccessContext shape change (with the one-line mock migration) and the concurrent-read fix as a distinct user-visible improvement
• pnpm lint, pnpm manypkg fix, pnpm format clean

Out of scope

• Any change to buildIncludeWithAccessControl's scoping behaviour, or to ADR-0022's decisions. The bound goes on hook execution; the Access Filter is not the mechanism here.
• Reverting fix(core): fail closed when the Access Filter can't scope a read past its depth cap #838's first-hop scoping — that reintroduces the fail-open.
• Reducing how wide hook-issued reads are for cost reasons. Once they terminate, that is a separate question and needs measurements behind it.
• The write path.
• Deprecating or discouraging reads inside resolveOutput hooks as a pattern.

Note for anyone blocked today

The reporter's per-call-site workaround holds: pass an explicit include: {} on reads issued inside a resolveOutput hook. It is per-call-site — one unguarded read anywhere brings the runaway back.

---

Generated by Claude Code

[borisno2]

This was generated by AI during triage.

Correction to the brief above: the design record has since merged (#845), so ADR-0023, the ADR-0022 correction, and the Resolve chain entry in CONTEXT.md are on main. Branch from main as usual — the instruction to base on claude/triage-844-ww8xmb is stale. Everything else in the brief stands, including that those files are the settled decision and should not be rewritten.

---

Generated by Claude Code