Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

PolicyPlugin: required to-one relations read back null via include/select, but ModelResult types them non-null

Abierto
  • ¿Algo no está bien?
#2,765 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

Read packages/orm/src/client/crud-types.ts around ModelResult's include branch and ModelSelectResult, plus WrapType and ModelFieldIsOptional, to see how the Optional flag reaches the relation type. Run tests/e2e/orm/policy/migrated/nested-to-one.test.ts ('read rejection for non-optional relation') to confirm the runtime null, then add a type-level assertion that m2.m1 must be nullable. Decide the gating mechanism (ExtResult already threads through ModelResult) and verify non-policy results stay unchanged. Done means required to-one relations are nullable only where the policy plugin can null them.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

With the policy plugin, a required to-one relation loaded through include or select can be null at runtime when the related record isn't readable. This is intentional and there's a test covering it, but the generated types don't know about it. ModelResult types the relation as non-nullable, so you can write m2.m1.value and it compiles fine and then crashes.

Optional to-one relations don't have this problem, they're already T | null.

Root cause

In packages/orm/src/client/crud-types.ts, both ModelSelectResult and the include branch of ModelResult use the schema optionality as the Optional flag:

ModelResult<
    Schema,
    RelationFieldType<Schema, Model, Key>,
    /* Select[Key] | I[Key] */,
    Options,
    ModelFieldIsOptional<Schema, Model, Key>,
    FieldIsArray<Schema, Model, Key>,
    ExtResult
>

WrapType only adds | null if that flag is true:

type WrapType<T, Optional = false, Array = false> =
    Array extends true
        ? Optional extends true ? T[] | null : T[]
        : Optional extends true ? T | null : T;

Nothing here knows that policies can null out a required relation.

Repro

tests/e2e/orm/policy/migrated/nested-to-one.test.ts ("read rejection for non-optional relation") already hits this exact case:

model M1 {
    id    String @id @default(uuid())
    value Int
    @@allow('create', true)
    @@allow('read', value > 0)
}

model M2 {
    id    String @id @default(uuid())
    m1    M1     @relation(fields: [m1Id], references: [id])
    m1Id  String @unique
    @@allow('all', true)
}

await db.$unuseAll().m1.create({
    data: {
        id: '1',
        value: 0,
        m2: { create: { id: '1' } },
    },
});

const m2 = await db.m2.findUnique({
    where: { id: '1' },
    include: { m1: true },
});

m2.m1.value; // compiles

TS infers m1: { id: string; value: number }. Actual value is m1: null. Runtime:

Cannot read properties of null (reading 'value')

The test only checks the runtime value so the type side never gets caught.

Fix idea

For to-one relations, force the Optional flag to true:

FieldIsArray<Schema, Model, Key> extends true
    ? ModelFieldIsOptional<Schema, Model, Key>
    : true

To-many is fine as is, unreadable records just get filtered out of the array.

Ideally this would only apply when the policy plugin is actually in use. Not sure what the best mechanism is. ExtResult is already threaded through ModelResult so maybe a type flag could ride along with that, or a client option.

We've been running this as a patch-package patch (no gating). After applying it TS found ~160 places in our frontend where we were dereferencing these relations without a null check. Some of those were reachable in production.

Can put together a minimal repro repo if needed but the schema/query above is basically it.

Environment
  • @zenstackhq/orm / @zenstackhq/plugin-policy 3.8.3, also reproduced on dev
  • PostgreSQL
  • Node 25.2.1, npm 11.6.2
Lenguaje dominante
TypeScript
Estrellas
2.9k
Forks
157
Merge medio
11 h 42 min
PR fusionados (30 d)
20

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de zenstackhq/zenstack

Todos los issues de zenstackhq/zenstack

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.