packages/language/src/validators/function-invocation-validator.ts (1)

240-252:Duplicated logic with_checkNanoid.

_checkCustomId is identical to_checkNanoid (lines 226–238). Consider extracting a shared helper like_checkPositiveFirstArg to avoid the duplication.

♻️ Proposed refactor

+    private _checkPositiveFirstArg(expr: InvocationExpr, accept: ValidationAcceptor) {+        const lengthArg = expr.args[0]?.value;+        if (lengthArg) {+            const length = getLiteral<number>(lengthArg);+            if (length !== undefined && length <= 0) {+                accept('error', 'first argument must be a positive number', {+                    node: expr.args[0]!,+                });+            }+        }+    }+     `@func`('nanoid')     private _checkNanoid(expr: InvocationExpr, accept: ValidationAcceptor) {-        // first argument must be positive if provided-        const lengthArg = expr.args[0]?.value;-        if (lengthArg) {-            const length = getLiteral<number>(lengthArg);-            if (length !== undefined && length <= 0) {-                accept('error', 'first argument must be a positive number', {-                    node: expr.args[0]!,-                });-            }-        }+        this._checkPositiveFirstArg(expr, accept);     }      `@func`('customId')     private _checkCustomId(expr: InvocationExpr, accept: ValidationAcceptor) {-        // first argument must be positive if provided-        const lengthArg = expr.args[0]?.value;-        if (lengthArg) {-            const length = getLiteral<number>(lengthArg);-            if (length !== undefined && length <= 0) {-                accept('error', 'first argument must be a positive number', {-                    node: expr.args[0]!,-                });-            }-        }+        this._checkPositiveFirstArg(expr, accept);     }

packages/language/test/function-invocation.test.ts (1)

418-434:Test coverage is incomplete compared to thenanoid() suite.

Thenanoid() length validation tests (lines 362–416) cover both positive acceptance and rejection of0 and-1. This suite only checks-1. Consider adding a positive-length acceptance test and acustomId(0) rejection test for parity.

tests/e2e/orm/client-api/custom-id.test.ts (1)

24-24:Unnecessaryasync ondescribe callback.

Thedescribe block doesn't use top-levelawait, so theasync modifier is unnecessary and could be removed.

packages/orm/src/client/options.ts (2)

43-65:model could useGetModels<Schema> for stronger typing.

ZModelFunctionContext on line 24 typesmodel asGetModels<Schema>, butCustomIdFunctionContext uses a plainstring. UsingGetModels<Schema> would give consumers autocomplete and type checking on the model name.

Also, minor grammar nit: lines 50 and 55 say "for which the ID should be generatedfor" — the trailing "for" is redundant.

Proposed fix

 export type CustomIdFunctionContext<Schema extends SchemaDef> = {     /**      * ZenStack client instance.      */     client: ClientContract<Schema>;      /**-     * The model for which the ID should be generated for.+     * The model for which the ID should be generated.      */-    model: string;+    model: GetModels<Schema>;      /**-     * The field for which the ID should be generated for.+     * The field for which the ID should be generated.      */     field: string;      /**      * The length of the ID as requested by the schema.      */     length?: number; };

---

65-65:CustomIdFunction is synchronous — async ID generation is unsupported.

Returningstring (notstring | Promise<string>) prevents users from generating IDs via async sources (e.g., a remote ID service, DB sequence lookup). SincefillGeneratedAndDefaultValues andevalGenerator inbase.ts are both synchronous, this would need broader changes to support, but it's worth flagging as a potential limitation consumers may hit.

If you don't plan to support async generation now, consider documenting this limitation in the JSDoc. If you do want to support it,evalGenerator andfillGeneratedAndDefaultValues would need to become async.