Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,765 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
typescript
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
TypeScript
Star
2.9k
Fork
157
Merge trung bình
11 giờ 42 phút
Pull request đã merge (30 ngày)
20

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của zenstackhq/zenstack

Tất cả issue của zenstackhq/zenstack

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.