Returning a 400 error for invalid input

[TheWisestOne]

If I define and API route such as

...
.build({
  input : z.object({
            entityId: z.string(),
            entityType: *{some type}*,
   }),
   handler: ...
})

and then I call that API but only provide one of those fields as input, for example { entityId: 'abcd' }

The API server responds with a 500, and I see

error: ZodError: [
  {
    "expected": *{some type}*,
    "received": "undefined",
    "code": "invalid_type",
    "path": [
      "entityType"
    ],
    "message": "Required ::: Input: undefined"
  }
]

However, for input validation, I would expect the API server to respond with a 400 (bad request) because the input provided by the user didn't match the specified input schema.

I'm wondering why this isn't the default behaviour (or if it is, what I might be doing wrong, because i did override the resultHandler / endpointFactory, but not in a way that was intended to affect this behaviour). Any help would be appreciated!

[TheWisestOne]

From a little more investigation, it seems like parseAndRunHandler in endpoint.ts will eagerly try to parse the input that is passed in, which will immediately throw an error in the case above.
I'm wondering if it would make sense to use zod's safeParse in this case, and in the event of a validation error, we throw an error with a 400 status code...or some other indication of the fact that this was an input parse error, as opposed to a generic server error.

Right now, we have no way to differentiate errors that happened during backend code execution (which should throw a 500) from errors that are thrown during this parse step, which IMO should return a 400. I am aware that I can override the resultHandler to change response codes according to my liking, but I currently have no way to tell whether an error was thrown during input parsing vs. during actual code execution, as far as I can tell.

Edit: I went one step further in my investigation and discovered that the defaultResultHandler does something like this to determine when to return a 400 for "input validation errors":

  if (error instanceof z.ZodError) {
    return 400;
  }

however, this doesn't work in our case because we ALSO use zod internally to validate data that comes out of our DB queries (ensuring that the query results in data of the type that we expect). If ever one of THOSE throws a zod error, we really should return a 500 because we either have garbage data in our db or a broken SQL query, both of which constitute a server-side error

[RobinTail]

Input validation errors usually lead to status code 400. There is an implementation and tests for that. I'm going to check your code sample to find out why you're getting 500.

[TheWisestOne]

From my understanding, the reason I get a 500 is that I overrode the defaultResultHandler for my API, which in your code has this logic, which isn't present in my result handler:

if (error instanceof z.ZodError) {
    return 400;
  }

My above comment is meant to explain that I don't want to do my validation in this way, because I have zod errors that might be thrown internally and should not result in a 400. Let me know if that understanding is wrong, and thanks for looking into it!

[RobinTail]

Hello, @TheWisestOne .

Thank you for the clarification. It made it clear now.
Well,

1. The library comes with the defaultResultHandler that provides a certain format of a positive/negative response.
2. In general, ResultHandler is the entity that is responsible for processing all errors and responding in a consistent way.
3. The library provides you an ability for customization: you can make you own ResultHandler,
   a. However, in this case you're responsible of making an implementation that suits your needs, not only in responding, but in processing errors as well.

The problem you state is that zod is not only used for the API I/O validation, but also for operating the database I/O, therefore, when it throws inside an Endpoint's handler, it leads to confusion while trying to distinguish between the API and the database I/O validation error.

What you can do in this regard.

• Option 1. Do not throw when validating the database I/O.
  • Consider using safeParse, as you mentioned yourself above. In this case you can handle such cases in place, with a simple conditional statement (or throwing basic Errors).

// this is your Endpoint's handler
const validation = schema.safeParse(valueFromDb);
if (!validation.success) {
  throw new Error(validation.error.message); // this is for 500, but you can handle it according to the local needs
} // else {
const theStuffFromDb = validation.data;

• Option 2. Transform the database I/O validation errors.
  • Consider extracting the database operation logic into a function. Let it throw ZodError as it is in you current implementation.
  • Call this function within try block, having in catch block create new (custom) errors out of thrown ones.

// this is your custom error file
class DbError extends Error {
  public override name = "DbError";
}

// this is your Endpoint's handler, or it can be extracted into another function
try {
  const theStuff = getTheStuff()
} catch (e) {
  if (e instance of ZodError) {
    throw new DbError(e.message);
  }
  // ... other possible cases
}

// and this is your custom error-to-status code transformer, for using in your custom ResultHandler
function getStatusCodeFromError(error: Error): number {
  if (error instanceof ZodError) {
    return 400;
  }
  if (error instanceof DbError) {
    return 500;
  }
  // ... other cases
  return 500;
}

Let me know what you think about it.

[RobinTail]

And, by the way, just in case you have any idea on some library improvement, that would make easier to implement such needs, please let me know.

[TheWisestOne]

Thanks for the response! Option 2 is something that I had considered, which would require a bit of code change throughout our API but seems much more tractable than option 1. I think I can accomplish what I need to using this, but I do wonder if it would be worth considering updating your library to prevent the need for this. zod is a useful tool for schema validation, and your current implementation of ResultHandler assumes that all zod errors will be thrown by the API input, which doesn't feel like a safe assumption for more complex applications.

I cloned your code and made a quick attempt at implementing such a pattern in the attached diff (if you aren't familiar, you can download this file and run git apply diff.patch to apply this patch to your local state).
Note: I am not as familiar with template types as I'd like to be, so excuse any type errors, but hopefully you can follow the idea behind the changes

diff.patch

if you think this is a reasonable direction, I am happy to make a PR against your repo, just wanted to run it by you first before taking that step

[TheWisestOne]

After a little more thought, I cleaned up my above diff to make significantly less structural changes, and got tests running locally so I was able to just put up a PR: #794

[RobinTail]

@TheWisestOne , sorry for delay.
It's a bit much things happening.
I keep in mind this request and I'm going to get back to it soon.
We will find a good solution.

[RobinTail]

@TheWisestOne ,
could you please check out my proposed solution to this problem:
#819

I believe it will allow you using zod for your database communication and at the same time to avoid mixing the possible validation issues in it with the ones that are IO-related.

Please let me know what you think.

[RobinTail]

@TheWisestOne ,

thank you so much for your patience and all the efforts you made regarding this problem.
The solution is about to be released in version 9.0.0-beta2 along with another potentially breaking change.

For the consistency I decided to create InputValidationError class, that you can utilize in custom ResultHandler for responding with 400. There is also a couple of error handling methods exposed. If you're using the default ResultHandler, no changes needed.

So, this should enable you using zod for database validations.

Consider checking the new version. Please let me know how it works.