Is it possible to disable output validation errors?

[ssteuteville]

I'd like output validation errors to result in a console.error on prod environments and a failed response on dev environments.

We're using nosql and every once in awhile we get a type wrong, i'd like for the endpoint to just return the data and not go into a complete failure state when that happens.

[RobinTail]

Hello @ssteuteville .

If you allow your endpoint to return wrong types, then the consumer of your API will receive not the ones you promised. Thus you'd just move the errors from one place to another — your Frontend will have to deal with null instead of the expected undefined, for example.
Instead, I'd suggest to create more loose output types using .or().
The types validation is the essential goal of the library. It's intended to operate in strict mode.

[RobinTail]

@ssteuteville ,

It is impossible due to ZOD library architecture to do what you want. Here is the line in my code:

this.outputSchema.parseAsync(output);

Output schema MAY contain transformations, therefore it requires the call of a parsing method on it.
However, even .safeParseAsync() wouldn't run transformations (ZodEffect) and ignore the validation issues at the same time.

This method returns an object containing either the successfully parsed data or a ZodError instance containing detailed information about the validation problems.

There is no possibility for a partial validation, or turning errors into warnings or anything like that.

[gmazoni]

I hit the same question today to help me migrating a legacy API. Maybe allow a raw output of the handler in the result handler? So I can verify if the name of the error is OutputValidationError and pass a non error status code and the raw output of the endpoint handler in the final response? Like:

My workaroud was to make a HOF to use NODE_ENV to return z.object({}).passthrough() or a desired schema to the output.

Losing coerce and other things, because it dont knows if is valid or not, so it must assume it's not always.

[RobinTail]

The correct way for checking the kind of error:

error instanceof OutputValidationError

Output validation is essential feature that ensures that the response comply the agreed contract.
However, the contract can be loose enough to allow uncertainty during the migration of legacy API,

@gmazoni

[gmazoni]

You are right, but it's worth nothing because the output is undefined in the ResultHandler when it occurs, thinking of getting the raw output in the result handler, we can not only ignore and force an output, but we can have the possibility to implement more logic, like, logging a warn, doing a fallback strategy, etc. Have you considered this? It can be a strategic resource to rollout the refactored endpoints, I can leave the desired contract and monitor/trace the cases where it's not agreed, then flip the switch to enforce. Imagining a scenario of making the contracts weaker an the beggining to avoid errors can leave lots of techinical debt in terms os schemas. After that I can fix the front-end that already deals with the wrong output of the backend.

[RobinTail]

The purpose of this library is strict compliance of data with the contract and consistency of responses.

Have you considered this?

Yes, and here is my final resolution to this problem:

1. If it's not clear what kind of data the endpoint responds with, it is the issue of that API implementation, not the one of framework/library.
2. If it's required purposely to break some constraints in the framework/library for the time of figuring out what is wrong with your implementation, there is a way for doing this — forking the library, but not making it breakable in production for everyone.