-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Description
A regression appears when running a Spring Boot 3.5.5 (Spring Framework 6.2.9 or later) application on AWS Lambda behind an Application Load Balancer. Requests that should produce HTTP 400 (Jakarta Bean Validation failure on a @Size(max=1)
field) return HTTP 502 only when invoked through the ALB. The same Lambda invoked via its Function URL correctly returns HTTP 400. Rolling back to Spring 6.2.8 restores correct 400 behavior through the ALB.
Environment:
Java 21 Lambda
Spring Boot 3.5.5
Spring Framework 6.2.9+ (regression); 6.2.8 works
Dependency: aws-serverless-java-container-springboot3:2.1.4
ALB → Lambda target group (multi-value headers enabled)
Expected: Invalid payload ({"name":"aa"}) → HTTP 400 with validation message.
Actual (6.2.9+ via ALB): HTTP 502 (no body).
Direct Lambda URL: Always returns 400 (all versions).
Reproduction steps (simplified):
Deploy stack (Lambda + ALB) with Spring 6.2.9+.
PUT /audit/v1/event-registrations/hello body: {"name":"aa"} via ALB → 502.
Same request via Function URL → 400.
Change Spring to 6.2.8 in build.gradle.kts, redeploy → ALB now returns 400.
Impact: ALB path unusable for clients relying on validation error semantics.
The ALB path through to the lambda application is unusable for clients relying on validation for springboot v3.5.5 using spring framework v6.2.10 affecting our service and security upgrades.