Change in DefaultErrorAttributes alters the shape of API validation error responses

[erizzo-cfa]

A change in Spring Boot 3.5 (here and here) has what I consider an unintended API side-effect in applications. Basically, it changes the existing JSON structure for validation errors in API responses - some data in the error details has been relocated, which could be considered a breaking change to API clients.
A more detailed explanation, along with a workaround, is in the StackOverflow question I asked before creating this issue.

Question is, was the resulting change in API responses intentional? Currently, the only mention of the change is this innocuous-sounding one:

The 'error' entry returned from ErrorAttributes now wraps all MessageSourceResolvable instances to ensure safe JSON serialization.

My thought as a Boot consumer is that, ideally, this new behavior would be disable-able via a config property. At a minimum, at least the release notes should mention this change can potentially alter API responses in a non-backwards-compatible way.

The workaround in the SO answer isn't completely awful, but it is tightly coupled to the implementation of DefaultErrorAttributes, requires developers to implement their own ErrorAttributes, not to mention spend the time (as I did) to determine why the response content is different in the first place (which cost me a non-trivial number of hours to track down).

Am I being unreasonable?
Could the release notes be updated at this point?
Would a PR that allows configuration-based disabling of the new wrapping behavior be considered?

[wilkinsona]

We think we may have gone a bit too far with the wrapping and are considering only wrapping potentially unsafe MessageSourceResolvable implementations, leaving ObjectError and FieldError as they were prior to Spring Boot 3.5. To help us to evaluate that change, can you please provide a minimal sample that reproduces the change in output that you've described in your question on Stack Overflow?

[erizzo-cfa]

I'll try to find some time to assemble a MRE with an endpoint that demonstrates the change.
In the meantime, I looked briefly at the proposed change and I have a comment: for the sake of extensibility and customization, please consider avoiding another static method in the Error class. Methods like that make it much more difficult to override or extend behavior. If the original change had been an overridable method in DefaultErrorDetails, it would be trivial to alter the behavioral change without the somewhat ugly workaround I had to implement.

[erizzo-cfa]

I'm a little embarrassed to say, but despite over a decade developing with Spring, I'm not able to get a simple sample app to produce error messages in the JSON response to a REST endpoint :-/ To be fair, it's been a long time since I had to bootstrap a Spring app from scratch, but what am I missing?
Here's the tiny sample which I thought should be enough, but despite setting the appropriate config properties, it isn't including error details in the responses.

curl --___location 'localhost:8080/echo' --header 'Content-Type: application/json' --data '{ "text": ""}'

Produces this response:

{
    "type": "about:blank",
    "title": "Bad Request",
    "status": 400,
    "detail": "Invalid request content.",
    "instance": "/echo"
}

DefaultErrorAttributes isn't being invoked at all.

[wilkinsona]

Thanks, @erizzo-cfa. You don't need to enable problem details. Without that, your sample produces the expected error details:

http POST localhost:8080/echo text=''    
HTTP/1.1 400 
Connection: close
Content-Type: application/json
Date: Mon, 07 Jul 2025 09:08:32 GMT
Transfer-Encoding: chunked

{
    "error": "Bad Request",
    "errors": [
        {
            "arguments": [
                {
                    "arguments": null,
                    "code": "text",
                    "codes": [
                        "message.text",
                        "text"
                    ],
                    "defaultMessage": "text"
                }
            ],
            "bindingFailure": false,
            "code": "NotBlank",
            "codes": [
                "NotBlank.message.text",
                "NotBlank.text",
                "NotBlank.java.lang.String",
                "NotBlank"
            ],
            "defaultMessage": "must not be blank",
            "field": "text",
            "objectName": "message",
            "rejectedValue": ""
        }
    ],
    "message": "Validation failed for object='message'. Error count: 1",
    "path": "/echo",
    "status": 400,
    "timestamp": "2025-07-07T09:08:32.921+00:00"
}

Upgrading to Spring Boot 3.5.3, the response then looks like this:

HTTP/1.1 400 
Connection: close
Content-Type: application/json
Date: Mon, 07 Jul 2025 09:10:29 GMT
Transfer-Encoding: chunked

{
    "error": "Bad Request",
    "errors": [
        {
            "arguments": [
                {
                    "arguments": null,
                    "code": "text",
                    "codes": [
                        "message.text",
                        "text"
                    ],
                    "defaultMessage": "text"
                }
            ],
            "cause": {
                "arguments": [
                    {
                        "arguments": null,
                        "code": "text",
                        "codes": [
                            "message.text",
                            "text"
                        ],
                        "defaultMessage": "text"
                    }
                ],
                "bindingFailure": false,
                "code": "NotBlank",
                "codes": [
                    "NotBlank.message.text",
                    "NotBlank.text",
                    "NotBlank.java.lang.String",
                    "NotBlank"
                ],
                "defaultMessage": "must not be blank",
                "field": "text",
                "objectName": "message",
                "rejectedValue": ""
            },
            "codes": [
                "NotBlank.message.text",
                "NotBlank.text",
                "NotBlank.java.lang.String",
                "NotBlank"
            ],
            "defaultMessage": "must not be blank"
        }
    ],
    "message": "Validation failed for object='message'. Error count: 1",
    "path": "/echo",
    "status": 400,
    "timestamp": "2025-07-07T09:10:29.972+00:00"
}

With the proposed changes in place, the response looks like this (the same as it did in 3.4.x):

HTTP/1.1 400 
Connection: close
Content-Type: application/json
Date: Mon, 07 Jul 2025 09:20:35 GMT
Transfer-Encoding: chunked

{
    "error": "Bad Request",
    "errors": [
        {
            "arguments": [
                {
                    "arguments": null,
                    "code": "text",
                    "codes": [
                        "message.text",
                        "text"
                    ],
                    "defaultMessage": "text"
                }
            ],
            "bindingFailure": false,
            "code": "NotBlank",
            "codes": [
                "NotBlank.message.text",
                "NotBlank.text",
                "NotBlank.java.lang.String",
                "NotBlank"
            ],
            "defaultMessage": "must not be blank",
            "field": "text",
            "objectName": "message",
            "rejectedValue": ""
        }
    ],
    "message": "Validation failed for object='message'. Error count: 1",
    "path": "/echo",
    "status": 400,
    "timestamp": "2025-07-07T09:20:34.999+00:00"
}

[wilkinsona]

please consider avoiding another static method in the Error class. Methods like that make it much more difficult to override or extend behavior. If the original change had been an overridable method in DefaultErrorDetails, it would be trivial to alter the behavioral change without the somewhat ugly workaround I had to implement.

There are advantages to Error being the class that performs the wrapping and the type that's serialised to JSON as it keeps related things in one place. The use of a static method on Error wouldn't be a problem if DefaultErrorAttributes made the wrapping behavior easier to override. Such a change wouldn't be appropriate for a maintenance release given that a workaround exists. I've opened #46310 for consideration in a future release.