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?

Comment From: 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?

Comment From: 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.

Comment From: 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.