@opensaas/stack-core 0.32.0 → 0.34.0

package/src/access/depth-limits.ts

@@ -0,0 +1,26 @@
+/**
+ * Maximum nesting depth of relation `include`s that the Access Filter
+ * (`buildIncludeWithAccessControl`) will auto-scope on a read.
+ *
+ * Security implication: this is an access-control boundary, not just a cost
+ * bound. Past this depth the engine cannot compute a row/field scope for a
+ * relation, so a caller-supplied `include` naming a relation at or beyond it
+ * must be treated as a denial (see `AccessScopeDepthExceededError`) rather
+ * than passed through unscoped — see ADR-0022 and issue #830.
+ */
+export const READ_INCLUDE_MAX_DEPTH = 5
+
+/**
+ * Maximum length of the resolve chain — the ordered sequence of `resolveOutput`
+ * hooks a read has entered, each entry extended by a hook that issues its own
+ * read (see `_resolveOutputChain` on `AccessContext`).
+ *
+ * This is a COST limit, not an access-control boundary: an acyclic chain
+ * genuinely can exceed it and still be correct (e.g. a virtual `Order.total`
+ * reading a virtual `LineItem.subtotal` reading further virtuals), so
+ * exceeding it omits the field and emits a single `console.warn` rather than
+ * throwing. Termination itself is guaranteed by the separate cycle guard,
+ * which refuses to re-enter a `(list, field)` pair already on the chain
+ * regardless of this cap. See ADR-0023.
+ */
+export const RESOLVE_CHAIN_MAX_LENGTH = 5

package/src/access/errors.ts

@@ -0,0 +1,62 @@
+import { READ_INCLUDE_MAX_DEPTH } from './depth-limits.js'
+
+/**
+ * Thrown when a caller-supplied `include` names a relation nested deeper than
+ * the Access Filter can scope (see `READ_INCLUDE_MAX_DEPTH`). Deliberately
+ * distinct from `ValidationError`: this is not bad user input, it is the
+ * engine refusing to return data it cannot prove is row/field scoped. Code
+ * that catches `ValidationError` to report form errors must not silently
+ * swallow this.
+ *
+ * Only an explicit caller selection past the depth cap triggers this — the
+ * auto-include silently stopping at the cap (no caller `include` involved)
+ * never throws. See ADR-0022 and issue #830.
+ */
+export class AccessScopeDepthExceededError extends Error {
+  public listKey: string
+  public fieldKey: string
+  public depth: number
+
+  constructor(listKey: string, fieldKey: string, depth: number) {
+    super(
+      `Cannot compute an access scope for "${listKey}.${fieldKey}" at include depth ${depth}: ` +
+        `this exceeds the Access Filter's maximum read-include depth (${READ_INCLUDE_MAX_DEPTH}). ` +
+        `A caller-supplied include this deep cannot be row- and field-scoped, so the read is denied ` +
+        `rather than returned unscoped. Restructure the query to fetch this relation separately.`,
+    )
+    this.name = 'AccessScopeDepthExceededError'
+    this.listKey = listKey
+    this.fieldKey = fieldKey
+    this.depth = depth
+  }
+}
+
+/**
+ * Thrown when a `resolveOutput` hook re-enters a `(list, field)` pair already
+ * on its own resolve chain — a hook whose own read (directly or transitively)
+ * comes back around to itself. Deliberately distinct from `ValidationError`
+ * (same reasoning as `AccessScopeDepthExceededError`): this is not bad user
+ * input, it is the engine refusing to run a hook chain that cannot terminate.
+ *
+ * This is a loud failure, not a Silent one, on purpose: a repeated pair never
+ * terminated before this guard existed, so no working application can depend
+ * on the old (hanging) behaviour, and staying silent here would return
+ * `undefined` for a field with nothing in the logs to explain why. Contrast
+ * with exceeding `RESOLVE_CHAIN_MAX_LENGTH`, which can happen on a chain that
+ * would otherwise terminate correctly and therefore only warns. See ADR-0023.
+ */
+export class ResolveOutputCycleError extends Error {
+  public chain: readonly { listKey: string; fieldKey: string }[]
+
+  constructor(chain: readonly { listKey: string; fieldKey: string }[]) {
+    const path = chain.map((link) => `${link.listKey}.${link.fieldKey}`).join(' → ')
+    super(
+      `resolveOutput cycle detected: ${path}. A hook that re-enters a (list, field) pair ` +
+        `already on its own resolve chain cannot terminate, so the read is refused rather than ` +
+        `left to recurse until the process runs out of memory. Restructure the hooks so the read ` +
+        `does not loop back into itself.`,
+    )
+    this.name = 'ResolveOutputCycleError'
+    this.chain = chain
+  }
+}

package/src/access/field-visibility.ts

@@ -2,6 +2,15 @@ import type { Session, AccessContext } from './types.js'
 import type { OpenSaasConfig, FieldConfig } from '../config/types.js'
 import { getRelatedListConfig } from './engine.js'
 import { checkFieldAccess } from './field-access.js'
+import { RESOLVE_CHAIN_MAX_LENGTH } from './depth-limits.js'
+import { ResolveOutputCycleError } from './errors.js'
+// NOTE: `context/index.ts` imports `filterReadableFields` from this module
+// (via the `access/index.ts` barrel) — this is an intentional cyclic
+// dependency, the same shape and for the same reason as the one documented in
+// `context/write-pipeline.ts`. `buildDbDelegate` is only INVOKED when a
+// `resolveOutput` hook actually runs (never during module evaluation), so by
+// the time it runs the export is fully initialised.
+import { buildDbDelegate } from '../context/index.js'
 
 /**
  * Field Visibility — phase 2 of the two-phase read (post-query).
@@ -36,6 +45,44 @@ type FieldVisibilityArgs = {
   context: AccessContext & { _isSudo?: boolean }
 }
 
+/**
+ * Derive the context passed to a single `resolveOutput` hook invocation: a
+ * NEW context object whose `_resolveOutputChain` extends the caller's chain
+ * with this hook's own `(list, field)` link. The chain is never mutated in
+ * place — this is what lets concurrent hook invocations (e.g. sibling rows in
+ * a to-many relation, filtered via `Promise.all`) each see their own chain
+ * rather than racing on one shared value (ADR-0023).
+ *
+ * A plain `{ ...context, _resolveOutputChain }` spread is not enough on its
+ * own: `context.db`'s operations capture their `context` at construction
+ * (see `populateDbDelegate`), so a hook that calls `context.db.x.findMany(…)`
+ * would otherwise reach the ORIGINAL closures — bound to the ORIGINAL
+ * context — and its read would silently fall back to the un-extended chain,
+ * defeating the cycle guard entirely. Rebuilding `db` via `buildDbDelegate`
+ * against the derived context is what makes a hook-issued read's own nested
+ * hooks actually observe the extended chain.
+ *
+ * `config` is required to rebuild `db`; callers that cannot supply one (e.g. a
+ * narrow unit test exercising field access in isolation) still get a correct
+ * chain for THIS hook's own cycle/cap check, but a read that hook issues
+ * would not carry the chain any further — those callers are not exercising
+ * the read pipeline, so there is nothing for it to reach.
+ */
+function deriveResolveOutputContext(
+  context: AccessContext & { _isSudo?: boolean },
+  link: { listKey: string; fieldKey: string },
+  config: OpenSaasConfig | undefined,
+): AccessContext & { _isSudo?: boolean } {
+  const derived: AccessContext & { _isSudo?: boolean } = {
+    ...context,
+    _resolveOutputChain: [...context._resolveOutputChain, link],
+  }
+  if (config) {
+    derived.db = buildDbDelegate(config, context.prisma, derived)
+  }
+  return derived
+}
+
 /**
  * The core Field Visibility step for a single field: check read access and, if
  * granted, produce the output value by running any `resolveOutput` hook.
@@ -58,8 +105,9 @@ async function resolveReadableFieldValue(params: {
   hookItem: Record<string, unknown>
   listKey: string | undefined
   args: FieldVisibilityArgs
+  config: OpenSaasConfig | undefined
 }): Promise<{ readable: false } | { readable: true; value: unknown }> {
-  const { fieldConfig, fieldName, value, accessItem, hookItem, listKey, args } = params
+  const { fieldConfig, fieldName, value, accessItem, hookItem, listKey, args, config } = params
 
   // Check field access (checkFieldAccess already handles sudo mode)
   const canRead = await checkFieldAccess(fieldConfig?.access, 'read', {
@@ -76,25 +124,44 @@ async function resolveReadableFieldValue(params: {
     // Cast to runtime type for generic execution
     // At runtime, the hook will receive the correct value type for the field
     const hook = fieldConfig.hooks.resolveOutput as unknown as ResolveOutputHookRuntime
-    // Increment depth counter to prevent infinite loops from hooks making DB queries
-    // that include relationships back to the same entity
-    args.context._resolveOutputCounter.depth++
-    try {
-      // Use Promise.resolve() to handle both sync and async hooks
-      const resolved = await Promise.resolve(
-        hook({
-          value,
-          operation: 'query',
-          fieldName,
-          listKey,
-          item: hookItem,
-          context: args.context,
-        }),
+    const link = { listKey, fieldKey: fieldName }
+    const chain = args.context._resolveOutputChain
+
+    // Cycle guard: a hook that would re-enter a (list, field) pair already on
+    // its own chain cannot terminate — refuse loudly rather than recurse
+    // until the process runs out of memory (issue #844, ADR-0023).
+    const alreadyOnChain = chain.some(
+      (entry) => entry.listKey === link.listKey && entry.fieldKey === link.fieldKey,
+    )
+    if (alreadyOnChain) {
+      throw new ResolveOutputCycleError([...chain, link])
+    }
+
+    // Cost cap: a chain this long is refused only as a cost limit, never a
+    // correctness one — an acyclic chain that works today can legitimately
+    // reach this. Omit the field and warn instead of throwing.
+    if (chain.length >= RESOLVE_CHAIN_MAX_LENGTH) {
+      const path = [...chain, link].map((entry) => `${entry.listKey}.${entry.fieldKey}`).join(' → ')
+      console.warn(
+        `resolveOutput: omitting "${listKey}.${fieldName}" — its resolve chain exceeded ` +
+          `RESOLVE_CHAIN_MAX_LENGTH (${RESOLVE_CHAIN_MAX_LENGTH}): ${path}. This is a cost limit, ` +
+          `not an access denial.`,
       )
-      return { readable: true, value: resolved }
-    } finally {
-      args.context._resolveOutputCounter.depth--
+      return { readable: false }
     }
+
+    // Use Promise.resolve() to handle both sync and async hooks
+    const resolved = await Promise.resolve(
+      hook({
+        value,
+        operation: 'query',
+        fieldName,
+        listKey,
+        item: hookItem,
+        context: deriveResolveOutputContext(args.context, link, config),
+      }),
+    )
+    return { readable: true, value: resolved }
   }
 
   return { readable: true, value }
@@ -116,7 +183,6 @@ export async function filterReadableFields<T extends Record<string, unknown>>(
   listKey?: string,
 ): Promise<Partial<T>> {
   const filtered: Record<string, unknown> = {}
-  const MAX_DEPTH = 5 // Prevent infinite recursion
 
   // Multi-column fields (e.g. storage image()/file() in Keystone-parity mode)
   // back several physical columns rather than one. Before the per-field pass,
@@ -153,14 +219,22 @@ export async function filterReadableFields<T extends Record<string, unknown>>(
     // Handle relationship fields - recursively filter fields within related items
     // Note: Access control filtering is now done at database level via buildIncludeWithAccessControl
     // This only handles field-level access (hiding sensitive fields)
+    //
+    // Deliberately uncapped: the row/relation scoping in access-filter.ts bounds
+    // what gets FETCHED (a caller include past its depth cap is now a denial,
+    // not a passthrough — see ADR-0022), so by the time a result reaches this
+    // function it is already a finite, acyclic tree whose depth was decided at
+    // the pre-query phase. Capping recursion again here independently of that
+    // cap used to let a relation be scoped correctly at the DB level while
+    // still returning with unfiltered fields past this function's own,
+    // separately-tracked limit (issue #830).
     if (
       config &&
       fieldConfig?.type === 'relationship' &&
       'ref' in fieldConfig &&
       fieldConfig.ref &&
       value !== null &&
-      value !== undefined &&
-      depth < MAX_DEPTH
+      value !== undefined
     ) {
       // Gate the relationship on read access before recursing.
       const canRead = await checkFieldAccess(fieldConfig?.access, 'read', {
@@ -220,6 +294,7 @@ export async function filterReadableFields<T extends Record<string, unknown>>(
       hookItem: workingItem,
       listKey,
       args,
+      config,
     })
 
     if (result.readable) {
@@ -258,6 +333,7 @@ export async function filterReadableFields<T extends Record<string, unknown>>(
       hookItem: filtered,
       listKey,
       args,
+      config,
     })
 
     if (result.readable) {

package/src/access/index.ts

@@ -26,6 +26,12 @@ export {
   buildIncludeWithAccessControl,
   mergeIncludeWithAccessControl,
   stripVirtualFieldsFromInclude,
+  toPrismaInclude,
 } from './access-filter.js'
+export type { AccessIncludeResult } from './access-filter.js'
 // Phase 2 — Field Visibility (post-query field stripping + resolveOutput).
 export { filterReadableFields } from './field-visibility.js'
+// Thrown when a caller include reaches past the depth the Access Filter can scope.
+export { AccessScopeDepthExceededError } from './errors.js'
+// Thrown when a resolveOutput hook's own resolve chain cycles back into itself.
+export { ResolveOutputCycleError } from './errors.js'

package/src/access/multi-column-read-write.test.ts

@@ -52,7 +52,7 @@ function makeContext(overrides: { isSudo?: boolean } = {}): AccessContext {
   return {
     session: null,
     _isSudo: overrides.isSudo ?? false,
-    _resolveOutputCounter: { depth: 0 },
+    _resolveOutputChain: [],
     // eslint-disable-next-line @typescript-eslint/no-explicit-any -- minimal context for unit test
   } as any
 }

package/src/access/relationship-count.test.ts

@@ -51,7 +51,7 @@ function makeContext(
   return {
     session: null,
     _isSudo: false,
-    _resolveOutputCounter: { depth: 0 },
+    _resolveOutputChain: [],
     db: findMany ? { user: { findMany } } : {},
     // eslint-disable-next-line @typescript-eslint/no-explicit-any -- minimal context for unit test
   } as any

package/src/access/relationship-label-filter.test.ts

@@ -46,7 +46,7 @@ function makeContext(): AccessContext {
   return {
     session: null,
     _isSudo: false,
-    _resolveOutputCounter: { depth: 0 },
+    _resolveOutputChain: [],
     db: {},
     // eslint-disable-next-line @typescript-eslint/no-explicit-any -- minimal context for unit test
   } as any

package/src/access/types.ts

@@ -290,12 +290,19 @@ export interface AccessContext<TPrisma extends PrismaClientLike = PrismaClientLi
   plugins: Record<string, unknown>
   _isSudo: boolean
   /**
-   * Internal mutable counter to track resolveOutput hook depth.
-   * When depth > 0, we skip auto-including relationships to prevent infinite loops
-   * when hooks make database queries that include relationships back to the original entity.
-   * We use a mutable object so that spreading the context preserves the reference.
+   * The resolve chain: the ordered sequence of `resolveOutput` hook
+   * `(listKey, fieldKey)` pairs a read has entered on the way to here. A
+   * top-level read starts with an empty chain. Each hook invocation is given
+   * a NEW context whose chain extends this one by its own pair — the chain is
+   * never mutated in place, so concurrent hook invocations (e.g. sibling rows
+   * in a to-many relation processed via `Promise.all`) never observe each
+   * other's chain. A hook that would re-enter a pair already on its own chain
+   * is refused (`ResolveOutputCycleError`) rather than left to recurse
+   * forever; a chain longer than `RESOLVE_CHAIN_MAX_LENGTH` is a separate,
+   * non-fatal cost limit. See ADR-0023 and the "Resolve chain" glossary entry
+   * in CONTEXT.md.
    */
-  _resolveOutputCounter: { depth: number }
+  _resolveOutputChain: readonly { listKey: string; fieldKey: string }[]
 }
 
 /**

package/src/context/index.ts

@@ -7,6 +7,7 @@ import {
   buildIncludeWithAccessControl,
   mergeIncludeWithAccessControl,
   stripVirtualFieldsFromInclude,
+  toPrismaInclude,
 } from '../access/index.js'
 import { ValidationError, DatabaseError } from '../hooks/index.js'
 import { getDbKey } from '../lib/case-utils.js'
@@ -433,7 +434,7 @@ export function getContext<
     // client, otherwise start empty and populate via plugin runtimes below.
     plugins: _sharedPlugins ?? {},
     _isSudo,
-    _resolveOutputCounter: { depth: 0 },
+    _resolveOutputChain: [],
   }
 
   // Create access-controlled operations for each list, populating `db` in place.
@@ -994,15 +995,19 @@ function createFindUnique<TPrisma extends PrismaClientLike>(
       // MERGE (not replace) a caller-supplied include with the access-controlled
       // include: the caller selects WHICH relations to fetch, access control
       // decides WHETHER and WITH WHAT filter (#566). A bare auto-include (no
-      // caller include) still uses the access-controlled include directly.
+      // caller include) still uses the access-controlled include directly. A
+      // caller include naming a relation past the depth the engine can scope
+      // throws `AccessScopeDepthExceededError` (issue #830) rather than being
+      // returned unscoped.
       include = args.include
         ? mergeIncludeWithAccessControl(
             args.include,
             accessControlledInclude,
             listConfig.fields,
             config,
+            listName,
           )
-        : accessControlledInclude
+        : toPrismaInclude(accessControlledInclude)
     }
 
     // Virtual fields have no database column. Whichever path produced
@@ -1128,15 +1133,19 @@ function createFindMany<TPrisma extends PrismaClientLike>(
       // MERGE (not replace) a caller-supplied include with the access-controlled
       // include: the caller selects WHICH relations to fetch, access control
       // decides WHETHER and WITH WHAT filter (#566). A bare auto-include (no
-      // caller include) still uses the access-controlled include directly.
+      // caller include) still uses the access-controlled include directly. A
+      // caller include naming a relation past the depth the engine can scope
+      // throws `AccessScopeDepthExceededError` (issue #830) rather than being
+      // returned unscoped.
       include = args?.include
         ? mergeIncludeWithAccessControl(
             args.include,
             accessControlledInclude,
             listConfig.fields,
             config,
+            listName,
           )
-        : accessControlledInclude
+        : toPrismaInclude(accessControlledInclude)
     }
 
     // Virtual fields have no database column. Whichever path produced
@@ -1445,7 +1454,7 @@ function createGet<TPrisma extends PrismaClientLike>(
     // Try to find the record
     const item = await model.findFirst({
       where,
-      include: accessControlledInclude,
+      include: toPrismaInclude(accessControlledInclude),
     })
 
     // If record exists, return it

package/src/context/nested-operations.ts

@@ -1312,17 +1312,10 @@ export async function processNestedOperations(
   // finding) so item-/inputData-dependent field-access rules cannot diverge between
   // Phase 5 and the connect site. `undefined` is tolerated (defaults to `{}`).
   parentInputData: Record<string, unknown> | undefined = undefined,
-  depth: number = 0,
 ): Promise<NestedOpsResult> {
-  const MAX_DEPTH = 5
-
   const afterTasks: AfterTask[] = []
   const includeFields = new Set<string>()
 
-  if (depth >= MAX_DEPTH) {
-    return { data, afterTasks, includeFields }
-  }
-
   const processed: Record<string, unknown> = {}
 
   for (const [fieldName, value] of Object.entries(data)) {

package/src/context/transaction-boundary.ts

@@ -55,9 +55,6 @@ export interface InvolvedList {
   originalItem: Record<string, unknown> | undefined
 }
 
-/** Max nesting depth walked when enumerating involved lists (matches nested-operations). */
-const MAX_DEPTH = 5
-
 /** Nested-op kinds whose payloads imply an involved list + operation. */
 const NESTED_OP_OPERATIONS: ReadonlyArray<{ kind: string; operation: WriteOperation }> = [
   { kind: 'create', operation: 'create' },
@@ -67,10 +64,49 @@ const NESTED_OP_OPERATIONS: ReadonlyArray<{ kind: string; operation: WriteOperat
   { kind: 'connectOrCreate', operation: 'create' },
 ]
 
+/** Distinct dedupe-key operations `NESTED_OP_OPERATIONS` can produce (create/update/delete). */
+const DISTINCT_OPERATION_COUNT = new Set(NESTED_OP_OPERATIONS.map((o) => o.operation)).size
+
 function isRelationshipField(fieldConfig: FieldConfig | undefined): boolean {
   return fieldConfig?.type === 'relationship'
 }
 
+/**
+ * The number of distinct (listKey, operation) involvement pairs the walk
+ * could ever record starting from `startListName` — computed from the
+ * CONFIG's relationship graph (not the payload), so it bounds the walk by
+ * what the schema can reach rather than by an arbitrary depth.
+ *
+ * Used as the saturation bound: once `walkNested` has recorded this many
+ * pairs, no further pair can be new, so it stops descending. This replaces
+ * the old depth cap as the cost bound (#835) — a payload nesting the config's
+ * lists more deeply than any previous cap no longer loses their
+ * transaction-boundary hooks, while a payload that repeats the same few
+ * lists still terminates promptly instead of walking every entry.
+ */
+function countReachableInvolvementPairs(
+  startListName: string,
+  startListConfig: ListConfig<any>, // eslint-disable-line @typescript-eslint/no-explicit-any -- ListConfig must accept any TypeInfo
+  config: OpenSaasConfig,
+): number {
+  const visited = new Set<string>([startListName])
+  const queue: Array<ListConfig<any>> = [startListConfig] // eslint-disable-line @typescript-eslint/no-explicit-any -- ListConfig must accept any TypeInfo
+
+  while (queue.length > 0) {
+    const current = queue.shift()!
+    for (const fieldConfig of Object.values(current.fields)) {
+      if (!isRelationshipField(fieldConfig)) continue
+      const relationshipField = fieldConfig as { type: 'relationship'; ref: string }
+      const related = getRelatedListConfig(relationshipField.ref, config)
+      if (!related || visited.has(related.listName)) continue
+      visited.add(related.listName)
+      queue.push(related.listConfig)
+    }
+  }
+
+  return visited.size * DISTINCT_OPERATION_COUNT
+}
+
 function asRecordArray(value: unknown): Array<Record<string, unknown>> {
   if (value == null) return []
   if (Array.isArray(value)) return value.filter((v) => v && typeof v === 'object')
@@ -117,9 +153,11 @@ function walkNested(
   config: OpenSaasConfig,
   out: InvolvedList[],
   seen: Set<string>,
-  depth: number,
+  maxPairs: number,
 ): void {
-  if (!data || depth >= MAX_DEPTH) return
+  // Every reachable pair is already recorded — no further recursion can add
+  // anything new, so stop instead of re-walking the rest of the payload.
+  if (!data || seen.size >= maxPairs) return
 
   for (const [fieldName, value] of Object.entries(data)) {
     const fieldConfig = fieldConfigs[fieldName]
@@ -150,10 +188,12 @@ function walkNested(
         })
       }
 
+      if (seen.size >= maxPairs) return
+
       // Recurse into each nested entry's own relationship payload.
       for (const entry of entries) {
         const childData = nestedInputData(kind, entry)
-        walkNested(childData, relatedListConfig.fields, config, out, seen, depth + 1)
+        walkNested(childData, relatedListConfig.fields, config, out, seen, maxPairs)
       }
     }
   }
@@ -187,9 +227,10 @@ export function enumerateInvolvedLists(args: {
     },
   ]
   const seen = new Set<string>([`${listName}:${operation}`])
+  const maxPairs = countReachableInvolvementPairs(listName, listConfig, config)
 
   // Delete has no nested payload to walk (inputData is undefined).
-  walkNested(inputData, listConfig.fields, config, out, seen, 0)
+  walkNested(inputData, listConfig.fields, config, out, seen, maxPairs)
 
   return out
 }

package/src/context/write-pipeline.ts

@@ -297,9 +297,10 @@ export async function runWritePipeline<TPrisma extends PrismaClientLike>(
  * construction, so the request-time `context.db` is bound to the ORIGINAL
  * client. We rebuild the delegates against `tx` via {@link buildDbDelegate},
  * reusing the request context's `session`, `storage`, `plugins`, `_isSudo`, and
- * the shared `_resolveOutputCounter` reference (so resolveOutput depth tracking
- * is preserved). Plugin runtimes are NOT re-executed; the existing
- * `plugins` object is reused as-is.
+ * the current `_resolveOutputChain` value (carried through unchanged, so a
+ * write issued from inside a `resolveOutput` hook keeps that hook's chain).
+ * Plugin runtimes are NOT re-executed; the existing `plugins` object is
+ * reused as-is.
  */
 function bindContextToTransaction<TPrisma extends PrismaClientLike>(
   args: WritePipelineArgs<TPrisma>,
@@ -313,7 +314,7 @@ function bindContextToTransaction<TPrisma extends PrismaClientLike>(
     storage: context.storage,
     plugins: context.plugins,
     _isSudo: context._isSudo,
-    _resolveOutputCounter: context._resolveOutputCounter,
+    _resolveOutputChain: context._resolveOutputChain,
   }
   // Rebuild the db delegate against `tx`, pointing back at `txContext` so hooks
   // reached through it also see the transactional context.

package/src/index.ts

@@ -62,6 +62,17 @@ export { resolveNavCounts, isListQueryStaticallyDenied } from './config/nav-coun
 // Validation error surfaced by write operations
 export { ValidationError } from './hooks/index.js'
 
+// Thrown by a read when a caller-supplied `include` names a relation nested
+// deeper than the Access Filter can scope (see ADR-0022). Distinct from
+// `ValidationError` — this is the engine refusing to return unscoped data, not
+// a user-input validation failure.
+export { AccessScopeDepthExceededError } from './access/index.js'
+
+// Thrown by a `resolveOutput` hook whose own read cycles back into a
+// `(list, field)` pair already on its resolve chain (see ADR-0023). Distinct
+// from `ValidationError` for the same reason as `AccessScopeDepthExceededError`.
+export { ResolveOutputCycleError } from './access/index.js'
+
 // Field self-containment validation — checks each field implements the
 // generation contract (getPrismaType / getTypeScriptType / getZodSchema, or
 // getPrismaRelation for relationships) so a misimplemented field fails early