Repository navigation
Feature request: Proactively raise errors if the response size is too large (e.g. >1MB for ALBResolver) #8352
Description
Use case
We use aws_lambda_powertools.event_handler.ALBResolver for internal HTTP requests. We ran into a case the other day where the lambda was returning successfully, but the response was over the 1MB limit for ALBs (docs), so the caller ended up getting a 502 status code.
I asked in the Discord channel and someone else said they've had a similar problem in the past:
It was tricky to track down because your lambda logs look great.
This happened today with the ALBResolver, but I'd imagine a similar problem could happen with APIGatewayHttpResolver and the 6MB response limit.
Solution/User Experience
The best idea I can come up with is:
- add a new flag to the ALBResolver initializer, like
enable_response_size_validation(and same forAPIGatewayHttpResolver) - When building the response, if the flag is enabled and the payload is too large for the corresponding resolver, raise a new exception, such as
ResponseSizeValidationError - Users can add their own
ResponseSizeValidationErrorhandler to log, etc.
I don't know if there's a more appropriate HTTP status code than 500 for this, since 413 Content Too Large is for the client.
To follow the letter of the law for backwards compatibility, the flag would have to be disabled by default. But I think (assuming no bugs) it would just be raising an error earlier and more visibly.
Alternative solutions
Logging when the response is too large? I'm not sure if there are other cases where the framework writes logs on its own.
I'm not sure if there's any built-in tracing that would you could add the response side and limit as attributes.Acknowledgment
- This feature request meets Powertools for AWS Lambda (Python) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET
Activity
chriselion commentedon Jul 28, 2026
If you like the proposed solution, I can try to submit a PR for it...
leandrodamascena commentedon Aug 28, 2026
Hi @chriselion, sorry for the slow response, and thanks for reporting this. I agree that this is a real observability gap: the Lambda invocation looks successful while the integration rejects the response afterward.
The opt-in validation direction makes sense. One important detail is that the ALB limit applies to the complete response JSON returned by Lambda, not only
body. We need to measure after JSON serialization, header and cookie serialization, compression, and base64 encoding. This matters especially for binary responses, since base64 increases their size by roughly one third.There is also a complication in the current resolver flow.
ResponseBuilder.build()runs after the route exception handling block. If validation raises from there today, a registered handler such as this would not catch it:We would need to adjust that flow so the final response can be measured and the exception can still reach the resolver's exception handler. The response returned by that handler should also be checked without creating a recursive error loop.
I would prefer to start with
ALBResolver, keep the option disabled by default, and expose the configured limit and actual serialized size on the exception. I agree that HTTP 413 would be misleading because the client request is not the problem. Without a custom handler, allowing the exception to surface would at least make the failure visible in the Lambda logs; with a handler, users could return a small 500 response and add their own logging.If you are still interested in working on this, I would be happy to review a PR scoped to ALB first.
MohammedAlkindi commentedon Sep 21, 2026
@chriselion are you still planning to take this? Your offer was July and the thread has been quiet in the month since leandrodamascena's scoping, so I would rather ask than duplicate your work. If you are on it, ignore me.
If not, I will pick up the ALB slice as scoped: opt-in and off by default, the check placed after
build()so it measures what actually goes over the wire including compression and base64, and raised through_call_exception_handlerso a custom handler can catch it.The gap is still there on
develop: greppingapi_gateway.pyforresponse_size,ResponseSizeExceededandcontent_lengthreturns nothing, andbuild()at line 835 runs outside thetryin_call_route, which is why an exception handler cannot see it today.chriselion commentedon Sep 21, 2026
@MohammedAlkindi Sorry for not replying on the thread sooner. I haven't had a chance to come back to this, and leandrodamascena's sounds more in-depth than what I had planned for (I was considering just checking the json payload, even if that would still allow some "false negatives" to slip through). So if you want to take it, go for it!
powertools-for-aws-oss-automation commentedon Sep 28, 2026
Warning
This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either reopen the issue, or open a new issue referencing this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.
github-actions commentedon Oct 15, 2026
This is now released under 3.36.0 version!