Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#2,765 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
typescript
领域
backend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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
主要语言
TypeScript
星标
2.9k
派生
157
平均合并
4 天 5 小时
30 天内合并 PR
22

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

zenstackhq/zenstack 的其他 Issue

查看 zenstackhq/zenstack 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。