Option to let invalid output pass through

[elmeister]

Hello
Thanks for the amazing library, it is clear that the project is made professionally and with ❤️
Regarding the question about output validation, raised in #647 and #695
Your point is clear - types should be guaranteed - and this point is respectable
Though in production API with real users, we can't allow ourselves to let API go haywire when someone used undefined instead of null.
Could you please reconsider adding an option to change this behaviour and add some flag to be able to still let initial payload pass through without any transformation? We would happily use this option to report a problem in bugsnag and take further actions.
Since as it is now, it's not usable for us, risks and cost of any error are too high and where before everything was handled "somehow", now it will become a complete disaster.
There are many cases apparently (including ours) when people are moving to your library to make things better, but these risks are stopping us from proceeding safely.

[RobinTail]

Could you please reconsider

#695 (reply in thread)

In short: there is no way to run transformations without validations.
There is no way for reconsideration. @elmeister

[RobinTail]

There are many cases apparently (including ours) when people are moving to your library to make things better, but these risks are stopping us from proceeding safely.

I understand, but currently there is no easy way of avoiding that risk.
If you really have concerns about that, I'd suggest to write tests of your endpoints and in general investing more effort in the quality of the code. Thus, you'd ensure that your code is production ready.
Disabling output validation is not only a thing that goes against my point view on the code quality,
but it's also impossible due to the architecture of ZOD library, that does not allow turning errors into warnings.

We have to parse the output produced by the endpoint's handler against the output schema since it may contain transformations or basically any type based on ZodEffects, or z.dateOut().

If you have any ideas on how to overcome this and avoid a big mess at the same time — you're welcome for any suggestions. @elmeister

[RobinTail]

@elmeister ,

when someone used undefined instead of null.

I've just realized that the reason for such cases could be that you didn't enable strict mode in your tsconfig file.
This is a prerequisite for using the library. Please check your tsconfig in order to make sure that strict compiler option is set to true.
Thus, you'd immediately be able to catch the cases you mention during the development, not in runtime.

[elmeister]

strict mode is enabled already. The case is that sometimes in the database some string can be empty '' instead of null. Some boolean value can be null instead of false. Some library can disable types applied to its output with any. There are plenty of cases when things can be just falsy or truthy, or sometimes some field can be missing, whatsoever.
In all these cases, as was already mentioned, where things were just "not ideal", API will won't work at all.
Anyways, your point is clear, let's agree to disagree.

[RobinTail]

I see. Okay.
Then I'd suggest to treat your database as another zero-trusted input method and acquire a data from it through ZOD schemas as well.

Something like that:

const schema = z.object({
  // string | empty string | undefined | null —> string | null
  someString: z.string().nullish().transform((subject) => subject || null),
  // boolean | null | undefined —> boolean
  someBoolean: z.boolean().nullish().transform((subject) => !!subject),
}).array();

// Array< { someString: string | null, someBoolean: boolean } >
const validRecords = schema.parse( await myDatabase.readRecords() );

@elmeister

[elmeister]

@RobinTail with all my respect - I already told that your project looks nice and solid; in many ways it looks more sane than tRPC, yet - what you're proposing with output validation is just not an option for real production API. Yes, we will catch all errors with bad data and lack of types at some moment - but again as already mentioned we can't pay the requested price - we would like to be warned about these errors, but not destroy such responses completely.
We had to make a difficult decision to not to proceed with express-zod-api because of the described issue, yet again we are inspired by many of your ideas and greatly appreciate them.