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?