Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DefaultErrorAttributes doesn't populate errors for MethodValidationResult #42013

Closed
sunruh opened this issue Aug 23, 2024 · 9 comments · May be fixed by #43330
Closed

DefaultErrorAttributes doesn't populate errors for MethodValidationResult #42013

sunruh opened this issue Aug 23, 2024 · 9 comments · May be fixed by #43330
Assignees
Labels
status: superseded An issue that has been superseded by another

Comments

@sunruh
Copy link

sunruh commented Aug 23, 2024

GH-39865 added support for MethodValidationResult to DefaultErrorAttributes but it filters the list errors published in the result and used for counting to instances of ObjectError.

With a method signature (in a RestController) of e.g. public void method(@PathVariable @Pattern(regexp = "^a.*") String parameter), this results in

  • message = "Validation failed for method='public void <class>.method(java.lang.String)'. Error count: 0"
  • errors = []

This is due to the fact, that the MethodValidationResult generated by MethodValidationAdapter will contain instances of ParameterValidationResult that have resolvable errors of type DefaultMessageSourceResolvable (and not ObjectError).

Spring Boot 3.3.1
Spring Framework 6.1.10

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 23, 2024
@wilkinsona
Copy link
Member

This was (somewhat) intentional as we wanted to be confident that the error was suitable for serializing to JSON. Filtering things so that only ObjectError instances are considered achieved this and aligned with what we already do for BindingResult. Perhaps we can relax things a little. To help us to investigate, please provide a minimal sample that reproduces the behaviour that you have described.

@wilkinsona wilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Aug 23, 2024
@sunruh
Copy link
Author

sunruh commented Aug 23, 2024

As an ObjectError extends DefaultMessageSourceResolvable, relaxing it should be ok.

Actually the example in spring-projects/spring-framework#32396 (comment) would cause it.

  • A validation problem regarding the RequestBody object would show up as that would create a ParameterErrors instance due to the problem being in a property (of the object).
  • A validation problem regarding the String parameter does not show up, as that creates a ParameterValidationResult (containing DefaultMessageSourceResolvable as errors)

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Aug 23, 2024
@wilkinsona
Copy link
Member

Thanks for the additional details but I'd really like to see a complete, minimal sample that reproduces this. Can you please provide one?

@wilkinsona wilkinsona added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Aug 28, 2024
@sunruh
Copy link
Author

sunruh commented Sep 2, 2024

spring-boot-issue-42013.zip

Here's a minimal sample. I based it on Spring Boot 3.3.3.

  • One of the test classes will show the problem
  • The other test class has a (potential) fix applied to addMessageAndErrorsFromMethodValidationResult() where it does not filter for ObjectError instances and the same test case succeeds.

The tests do not use MockMvc on purpose as otherwise the error controller would never be called.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Sep 2, 2024
@philwebb
Copy link
Member

philwebb commented Sep 4, 2024

I'm wondering if we should create our own wrapper object for serialization and try to support the MessageSourceResolvable. Looking at the code, there's a lot of overlap with the reactive and servlet version of DefaultErrorAttributes and I wonder if now might also be the time to try and pull the common code up to the org.springframework.boot.web.error package.

@philwebb philwebb added the for: team-meeting An issue we'd like to discuss as a team to make progress label Sep 4, 2024
@philwebb
Copy link
Member

philwebb commented Sep 5, 2024

We discussed this today and would like to add a wrapper object. This will be a slight breaking change and the Javadoc of DefaultErrorAttributes will need to be updated. We'll need to provide a way for the user to get the original ObjectError if they wish to.

@philwebb philwebb added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged status: feedback-provided Feedback has been provided for: team-meeting An issue we'd like to discuss as a team to make progress labels Sep 5, 2024
@philwebb philwebb added this to the 3.x milestone Sep 5, 2024
@YongGoose
Copy link

@philwebb

Can i contribute?

@philwebb
Copy link
Member

Absolutely @YongGoose, that would be most welcome. We won't be able to merge it for 3.4 but it can be a 3.5 enhancement.

@philwebb
Copy link
Member

philwebb commented Dec 3, 2024

Closing in favor of PR #43330. Thanks @YongGoose

@philwebb philwebb closed this as not planned Won't fix, can't repro, duplicate, stale Dec 3, 2024
@philwebb philwebb removed the type: enhancement A general enhancement label Dec 3, 2024
@philwebb philwebb removed this from the 3.x milestone Dec 3, 2024
@philwebb philwebb added the status: superseded An issue that has been superseded by another label Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants