Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,765 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
typescript
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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
Dominant language
TypeScript
Stars
2.9k
Forks
157
Avg merge
11h 42m
Merged PRs (30d)
20

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from zenstackhq/zenstack

All issues in zenstackhq/zenstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.