Skip to content

Fix Zod validation for non-string enums in OpenAPI parser#4

Merged
mikesellitto merged 1 commit into
mainfrom
mike/parser-enum-fix
Feb 19, 2026
Merged

Fix Zod validation for non-string enums in OpenAPI parser#4
mikesellitto merged 1 commit into
mainfrom
mike/parser-enum-fix

Conversation

@mikesellitto

Copy link
Copy Markdown
Contributor

Currently, The OpenAPI parser in src/parser.ts converts all enum fields to z.enum(), which only supports string values. When the OpenAPI spec defines an non-string enum (i.e. visType with "type": "integer", "enum": [0, 1, 2]), the resulting Zod schema rejects every input

This PR makes it so that we use z.union of z.literal values for non-string enums instead.

Closes ENG-9167

@linear

linear Bot commented Feb 18, 2026

Copy link
Copy Markdown
ENG-9167 MCP server silently fails on OpenAPI endpoints with integer enums

The OpenAPI parser in src/parser.ts converts all enum fields to z.enum(), which only supports string values. When the OpenAPI spec defines an integer enum (e.g. visType with "type": "integer", "enum": [0, 1, 2]), the resulting Zod schema rejects every input

@dp-franklin dp-franklin left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment thread src/parser.ts
return z.union(
schema.enum.map((val: any) => z.literal(val)) as [
z.ZodLiteral<any>,
z.ZodLiteral<any>,

@dp-franklin dp-franklin Feb 19, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi: I assume that the z.union type requires at least two items in the array, but only one item is actually required at runtime. (0 will throw)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ty, addressed in the latest force push

z.enum() only accepts string values, so integer enums like  visType: [0,
1, 2] on change request endpoints would fail validation before the
request ever reached our api, producing a generic "tool execution
failed" error. Now we use z.union of z.literal values for non-string
enums instead.
@mikesellitto
mikesellitto merged commit 2ae51ff into main Feb 19, 2026
2 checks passed
@mikesellitto
mikesellitto deleted the mike/parser-enum-fix branch February 19, 2026 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants