Row level security type error for Rules, not accepting optional property in generated DataModel

[AtAFork]

For the rules object (just like in the blog post) I'm trying to do const rules: Rules<QueryCtx, DataModel> = { and getting a type error:

Type ' my stuff here ...' does not satisfy the constraint 'GenericDataModel'.
  Property 'users' is incompatible with index signature.
    Type '{ document: { _id: Id<"users">; _creationTime: number; stripeSubscriptionStatus?: string | undefined ...' is not assignable to type 'GenericTableInfo'.
      Types of property 'document' are incompatible.
        Type '{ _id: Id<"users">; _creationTime: number; stripeSubscriptionStatus?: string | undefined; ... }' is not assignable to type 'GenericDocument'.
          Property 'stripeSubscriptionStatus' is incompatible with index signature.
            Type 'string | undefined' is not assignable to type 'Value'.
              Type 'undefined' is not assignable to type 'Value'.ts(2344)

My users table schema has stripeSubscriptionStatus: v.optional(v.string()),, which (from my understanding) is ok to do within a table schema in Convex

versions

    "convex": "^1.25.4",
    "convex-helpers": "^0.1.104",

[ianmacartney]

Can you do npm ls convex to see if they're using different versions of Convex?
Or if you're in a monorepo, making sure they're referencing the same version - maybe there's a cache to clear or something

[AtAFork]

all using 1.25.4

├─┬ @convex-dev/migrations@0.2.9
│ └── convex@1.25.4 deduped
├─┬ convex-helpers@0.1.104
│ └── convex@1.25.4 deduped
└── convex@1.25.4

[AtAFork]

Also tried npm cache clean --force & removing node_modules as well as package-lock.json, but same result (and not in a monorepo)

[ianmacartney]

This works for me, so I'm not sure how to debug. If you have a minimal repro in a repo I can clone I can debug further:

const schema = defineSchema({
  users: defineTable({
    stripeSubscriptionStatus: v.optional(v.string()),
  }),
});
type DataModel = DataModelFromSchemaDefinition<typeof schema>;
type QueryCtx = GenericQueryCtx<DataModel>;

const rules: Rules<
  QueryCtx,
  DataModel
> = {
  users: {
    read: async (ctx, doc) => {
      return "active" === doc.stripeSubscriptionStatus;
    },
  },
};

[AtAFork]

Hm I even get the error even when just doing:

import type { GenericQueryCtx } from 'convex/server'
import type { DataModel } from './_generated/dataModel'

type QueryCtx = GenericQueryCtx<DataModel>

so it's unrelated to Rules. I do have "exactOptionalPropertyTypes": true in my tsconfig, and the type generated for stripeSubscriptionStatus from DataModel shows stripeSubscriptionStatus?: string | undefined.

Seems like that may be causing the issue? I very much rely on that compiler flag throughout my codebase though so wouldn't be able to turn it off

[ianmacartney]

Yes that tsconfig flag (especially if it's in convex/tsconfig.json) is the issue here. Say more about how you rely on it in your codebase?

…

On Tue, Sep 2, 2025 at 3:06 PM Adam ***@***.***> wrote: *AtAFork* left a comment (get-convex/convex-helpers#738) <#738 (comment)> Hm I even get the error even when just doing: import type { GenericQueryCtx } from 'convex/server' import type { DataModel } from './_generated/dataModel' type QueryCtx = GenericQueryCtx<DataModel> so it's unrelated to Rules. I do have "exactOptionalPropertyTypes": true in my tsconfig, and the type generated for stripeSubscriptionStatus from DataModel shows stripeSubscriptionStatus?: string | undefined. Seems like that may be causing the issue? I very much rely on that compiler flag throughout my codebase though so wouldn't be able to turn it off — Reply to this email directly, view it on GitHub <#738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQWY3NMKCUNSQU7HIVLT3QYIHFAVCNFSM6AAAAACEQAMQZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBWHEZTSNJUGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[AtAFork]

Sure, here's why I use exactOptionalPropertyTypes:

• General TS (not convex-specific): It prevents accidentally including foo: undefined when I only mean to include foo if it’s defined: const abc = { foo: maybeValue, bar: 123 }; // want to omit foo if undefined

  Without the exactOptionalPropertyTypes flag, { foo: undefined, bar: 123 } compiles; with the flag, TS errors and surfaces the upstream logic bug (relevant in the case where foo was the result of a calculation or a find on an array, and I'd only want to include that result as an attribute in abc if it were not undefined.

• Convex semantics: since convex treats omission vs undefined differently:

  Passing {a: undefined} removes the field ‘a’ … while passing {} does not change the field.

  • ctx.db.patch(id, { foo: undefined }) removes foo
  • ctx.db.patch(id, {}) leaves foo unchanged

  With the flag on, TS won’t let me construct { foo: undefined } unless I explicitly type it that way, which reduces accidental field drops.

Convex codegen emits prop?: T | undefined for v.optional(T), but at runtime convex never returns undefined for a field, it's just omitted. So the generated types encode an impossible stored state, which is what conflicts with exactOptionalPropertyTypes.

I know this isn't specific to convex-helpers and more of a deeper issue with convex's codegen. Would it be possible for codegen (or helpers) to normalize optionals to prop?: T instead, so the types match runtime behavior?

[ianmacartney]

Understood, and that resonates with other feedback. I wasn't sure if there was some library or fundamental limitation vs. code hygiene / preference.

We don't have a plan to change the types right now unfortunately, and I suspect doing so would cause a lot of type errors for folks, which is a big problem for customers with hundreds of thousands of LOC already.

It would be nice if we could opt into defining the more correct types, though it's not via codegen but through dynamic typing. We do have a way to explicitly codegen the full API, but not the full schema - that could be an intervention point.

Just for completeness, there's other behavior around undefined:

1. You can return undefined from functions or pass undefined via arguments and they'll be serialized out, so they're "valid" to pass through, but will never be read.
2. You can pass undefined to inserts and they'll similarly be omitted
3. You can do an index lookup via the undefined value on an optional field.

I personally feel like it's gymnastics to optionally set a value. I end up with a lot of ...(maybeValue ? { maybeValue } : {}) or lose out on some benefits of satisfies capturing actual values..

But all that to say, unfortunately for this convex-helpers issue it's a wontfix for now - though filing the issue on get-convex/convex-backend could help surface that discussion - I know Tom has internally been advocating for this for years - and would have been easier to pull off years ago