inputValidator validation errors lose structure during serialization - issues array becomes JSON string in error.message #6428

Activity

1. alexander-zuev commented on Jan 20, 2026

   

   alexander-zuev

   on Jan 20, 2026

   ContributorAuthor

   More actions

   Additional finding: Function middleware types prevent custom error responses

   While investigating workarounds, I discovered a fundamental type constraint in createMiddleware({ type: 'function' }).

   The Problem

   Function middleware's .server() handler is typed to ONLY return next() result. Looking at createMiddleware.d.ts line 92-100:

   export type FunctionServerResultWithContext<...> = {
     'use functions must return the result of next()': true;  // <-- Literal marker enforcing next()
     '~types': {...};
     context: ...;
     sendContext: ...;
   };

   This means middleware cannot return custom error responses like:

   // This works at RUNTIME but fails TypeScript
   export const errorHandler = createMiddleware({ type: 'function' }).server(
     async ({ next }) => {
       try {
         return await next()
       } catch (error) {
         setResponseStatus(422)
         return { success: false, error: { code: 'VALIDATION_ERROR', issues } }  // TS Error!
       }
     },
   )

   Contrast with Request Middleware

   Request middleware (type: 'request') CAN return Response (line 182):

   export type RequestMiddlewareServerFnResult<...> = 
     Promise<RequestServerResult<...> | Response> | Response;  // Response allowed!

   Current Workaround

   Using as never type assertion (cleaner than as any):

   return { success: false, error: {...} } as never

   Runtime behavior is correct - TanStack serializes the custom response to the client. But the types don't support this valid use case.

   Suggestion

   Consider allowing function middleware to return custom responses for error handling, similar to how request middleware can return Response. Error handling middleware is a common pattern that the current types don't accommodate.

   👍React with 👍2Reacted by Manuel MV and Rocco Maniscalco
2. JClackett commented on Apr 2, 2026

   

   JClackett

   on Apr 2, 2026

   Last edited by JClackett

   More actions

   YESSS! ive just run into this, and its super unfortunate that the inputValidator replaces the ZodError.

   if it kept the ZodError class, we could build a custom serialiser that parses the zod issues on the frontend so we can display nice messages, but now that its just an Error class theres no meaningful way of doing this.

   The only way now is to wrap every inputValidator scheme with a custom function that rethrows with a custom error class.

   It's this line here:
   

   router/packages/start-client-core/src/createServerFn.ts

   Line 759 in 5a81726

   throw new Error(JSON.stringify(result.issues, undefined, 2))

   which I understand because its within the standard schema branch, and its cool that it serialises the issues, but if we can't tag it as a validation parse error, what would be the most type-safe/reliable way of knowing its a validation issue?

   Maybe start could throw a custom "standard schema" class or something, so that we can at least check its instanceof at least?

   You could then create a serializationAdapter that checks for this and then use that on the client to get structured validation errors.

   // would just need to be something like this? Issue from standard schema
   export class SomeCustomErrorClass <T extends ReadonlyArray<Issue>[]> extends Error {
     public readonly issues: Issue[]
     constructor(issues: T) {
       this.issues = issues
       // etc etc
     }
   }
   
   // then a custom serialiser
   export const serializedZodIssuesAdapter = createSerializationAdapter({
     key: "serializedZodIssues",
     test: (value: unknown) => {
       return value instanceof SomeCustomErrorClass
     },
     toSerializable: (value) => JSON.stringify(value.issues),
     fromSerializable: (value) => {
       const issues = JSON.parse(value) as $ZodIssue[]
       return new SomeCustomErrorClass(issues)
     },
   })
   
   // in your ui you could then render the issues
   function FormFieldErrors({ error }: { error: Error | null }) {
     if (!error || !(error instanceof SomeCustomErrorClass)) return null
     if (error.issues.length === 0) return null
     return (
       <ul className="list-disc pl-4 text-muted-foreground">
         {error.issues.map((issue) => (
           <li key={issue.path.join(".")}>
             {issue.message} for {issue.path.join(".")}
           </li>
         ))}
       </ul>
     )
   }

   👍React with 👍1Reacted by Rocco Maniscalco
3. JClackett commented on Apr 2, 2026

   

   JClackett

   on Apr 2, 2026

   Last edited by JClackett

   More actions

   For now im just wrapping every zod schema with a custom parse zod function:

   export function parseZod<Schema extends z.ZodSchema>(schema: Schema): (input: z.input<Schema>) => z.output<Schema> {
     return (input: z.input<Schema>) => {
       const res = schema.safeParse(input)
       if (res.success) return res.data
       throw new SerializedZodIssues(res.error.issues)
     }
   }

   Works well, but just a bit annoying having to remember to use this everytime