Feature request: Injectable error handler for parser

[codyfrisch]

Use case

Today when there is a parsing error (except when using safeParse) the error is thrown uncaught. This could be potentially undesired, as we may want to instead return a specific response to the request - I'm thinking specifically API Gateway here but others might benefit too (I just don't have those use cases).

Solution/User Experience

Add an error handler function to ParserOptions. In the decorator add a try/catch around the parse, and in the catch if the error handler function is present, use it and return its value otherwise rethrow the error.

This way we can handle errors JUST from the parse function, rather than some other upstream decorator catching ZodError (or whatever) from where exactly? maybe not just the parser.

Alternative solutions

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

Hi @codyfrisch, thanks for opening this issue.

If I understand correctly, you're suggesting we add something like this:

const errorHandler = (error) => {
  // handle error
}

class Lambda {
 @parser({ schema: SQSSchema, errorHandler })
 async handler(event, context) {
  // your code
 }
}

If this is the case, what's the benefit over doing this (which is the alternative you suggested)?

class Lambda {
 @parser({ schema: SQSSchema, safeParse: true })
 async handler(event, context) {
  if (event.error) return errorHandler(event.error);
  const data = event.data;
  // your code
 }
}

[codyfrisch]

Because @parser may not be the final decorator called. Subsequent decorators would need to know how to handle the safeParse result - or yet another decorator would be needed that handles the safeParse result and the customizable error handling.

[dreamorosi]

Thanks - our docs don't do a good job here, but the Middy.js middleware and class method decorator are intended for those cases where you want to just parse/validate the event and fail-fast. If you want more control over the parsing and error handling you might want to call parse on the schema directly.

In the Python version of Powertools for AWS we also export a parse function which you'd be able to use like this:

class Lambda {
 async handler(event, context) {
  const result = parse({ event, schema: SQSSchema, safeParse: true })
  if (result.error) return errorHandler(event.error);
  const data = result.data;
  // your code
 }
}

Would something like this get closer to what you need?

I'm not necessarily pushing back against your idea, as a matter of fact I encountered the same issue you're describing in another codebase myself and I ended up implementing a custom decorator that catches/formats the error into an API Gateway response, so I can see the problem.

At this stage I'm primarily trying to find ways to address your issue without adding a new feature because that will require further discussion and most likely the involvement of other Powertools for AWS versions for feature parity's sake.

[leandrodamascena]

Hey there! Good to see you again bringing good ideas @codyfrisch to improve the Powertools experience. I really appreciate your collaboration.

While I'll let to you both to discuss about TS experience, middleware and TS ecosystem, I'd like to reply to @dreamorosi's comment.

At this stage I'm primarily trying to find ways to address your issue without adding a new feature because that will require further discussion and most likely the involvement of other Powertools for AWS versions for feature parity's sake.

This doesn't necessarily apply to Python, as the languages work slightly differently. When using the parser in the Python version, the customer has two methods for validating the event:

Fast fail
Customers will use the @event_parser decorator to decorate the Lambda handler, and there is no way to catch this exception. Customers can wrapper this decorator inside another decorator, but I've never seen that.

Parsing the event using custom logic
Customers can use the parse function to validate the event within the Lambda handler. In this case, they can create custom logic to catch exceptions and do some stuff.

In both cases, we will throw 1 custom exception:

InvalidModelTypeError - If we are unable to "compile" the TypeAdapter object and generate the CoreSchema, or if the provided model is not a valid Pydantic object. Imagine you passed a string as the model, this will fail.

If the schema is valid and the object is a valid Pydantic object, but something goes wrong, we raise it directly from Pydantic. In most cases, this will raise a ValidationError because there was some error parsing/dumping the data into the model and customers are used to it.

Just for additional context, when we released v3 we tried to wrap Pydantic exceptions into a PowertoolsCustomException (i don't remember exactly the name) but customers complained about that and we reverted.

Pls let me know if I can help with anything else.

[leandrodamascena]

Opz, I saw @dreamorosi covered it here: #4191 (comment)

My bad, forget about my comment.

[codyfrisch]

At this stage I'm primarily trying to find ways to address your issue without adding a new feature because that will require further discussion and most likely the involvement of other Powertools for AWS versions for feature parity's sake.

That discussion actually what I was trying to spur by making this a feature request and not a general question (how do I...)! I personally have already worked around this with a custom parser decorator used with the Powertools schemas.

The main reason I don't parse in the handler, is I have multiple additional decorators that need the parsed event (in my case, I deserialize the body as well with with the Zod schema I use). I much prefer this to boilerplate inside the handler method - it makes it obvious what is meaningful business logic.