Inconsistent Application of Enum in Generated Zod Schemas

[jascenc1]

I'm encountering an issue where the surql-gen tool inconsistently applies z.enum([...])/z.enum([...]).optional() in the generated zod schemas based on surrealdb defs. Specifically, in some cases, the tool correctly generates the enum for fields defined with the following:

DEFINE FIELD blah ON TABLE blah_table type option<string>
   ASSERT $value  = NONE OR $value IN ['hello', 'there'];

DEFINE FIELD blah ON TABLE blah_table type option<string>
   ASSERT $value  INSIDE ['hello', 'there'] PERMISSIONS FULL;

while in other cases, it does not. Instead, the generated zod schema might fall back to z.string() or z.unknown()

Inconsistency Details

• The inconsistency occurs even when the SurrealDB defs are structurally similar
• There is no clear pattern or difference in the defs that would explain why some work and nothers do not
• The inconsistency makes it challenging to trust the generated schemas without manual verification

Additional Examples

This is seen within the same schema file as well (note fieldFour. Also the tool incorrectly handles surreal geometry data type, but that can be saved for another issue):

surql file

DEFINE TABLE my_table SCHEMAFULL PERMISSIONS NONE;

DEFINE FIELD fieldOne ON TABLE my_table TYPE string
                ASSERT $value IN ["Y", "N"];
DEFINE FIELD fieldTwo ON TABLE my_table TYPE string
                ASSERT $value IN ["Hello", "There", "Foo", "Bar"];
DEFINE FIELD fieldThree ON TABLE my_table TYPE string
                ASSERT string:: len($value) <= 38;
DEFINE FIELD fieldFour ON TABLE my_table TYPE string
                ASSERT $value IN ["Um", "D", "F", "E", "C", "A", "B", "G"];
DEFINE FIELD fieldFive ON TABLE my_table TYPE string
                ASSERT $value IN ["Random", "Value"];
DEFINE FIELD fieldSix ON TABLE my_table TYPE option < string > DEFAULT NONE
                ASSERT IF $value != NONE THEN string:: len($value) <= 100 ELSE TRUE END;
DEFINE FIELD fieldSeven ON TABLE my_table TYPE geometry<line>;
DEFINE FIELD fieldEight ON TABLE my_table TYPE float;
DEFINE FIELD fieldNine ON TABLE my_table TYPE string
                ASSERT $value IN ["placeholder"];

INFO FOR TABLE my_table in surrealist.app

{
                fields: {
                                fieldOne: "DEFINE FIELD fieldOne ON my_table TYPE string ASSERT $value INSIDE ['Y', 'N'] PERMISSIONS FULL",
                                fieldTwo: "DEFINE FIELD fieldTwo ON my_table TYPE string ASSERT $value INSIDE ['Hello', 'There', 'Foo', 'Bar'] PERMISSIONS FULL",
                                fieldThree: 'DEFINE FIELD fieldThree ON my_table TYPE string ASSERT string::len($value) <= 38 PERMISSIONS FULL',
                                fieldFour: "DEFINE FIELD fieldFour ON my_table TYPE string ASSERT $value INSIDE ['Um', 'D', 'F', 'E', 'C', 'A', 'B', 'G'] PERMISSIONS FULL",
                                fieldFive: "DEFINE FIELD fieldFive ON my_table TYPE string ASSERT $value INSIDE ['Random', 'Value'] PERMISSIONS FULL",
                                fieldSix: 'DEFINE FIELD fieldSix ON my_table TYPE option<string> DEFAULT NONE ASSERT IF $value != NONE THEN string::len($value) <= 100 ELSE true END PERMISSIONS FULL',
                                fieldSeven: 'DEFINE FIELD fieldSeven ON my_table TYPE geometry<line> PERMISSIONS FULL',
                                fieldEight: 'DEFINE FIELD fieldEight ON my_table TYPE float PERMISSIONS FULL',
                                fieldNine: "DEFINE FIELD fieldNine ON my_table TYPE string ASSERT $value INSIDE ['placeholder'] PERMISSIONS FULL"
                },
}

Generated Zod Schema:

export const switchPairInputSchemaGen = z.object({
    fieldOne: z.enum(['Y', 'N']),
    fieldTwo: z.enum(['Hello', 'There', 'Foo', 'Bar']),
    fieldThree: z.string().max(38),
    fieldFour: z.unknown(),
    fieldFive: z.enum(['Random', 'Value']),
    fieldSix: z.string().max(100).optional(),
    fieldSeven: z.unknown(),
    fieldEight: z.number(),
    fieldNine: z.enum(['placeholder'])
});

Due to the sporadic nature of the issue, I'm unable to provide a clear set of reproducible steps, however, any assistance in identifying the root cause or improving the consistency of enum handling would be greatly appreciated

[sebastianwessel]

thx for you feedback. We will investigate it.