HttpMediaTypeNotAcceptableException exception missing when using ContentNegotiationConfigurer

[membersound]

spring-boot-stater-parent.2.4.3 Test OK
spring-boot-stater-parent.2.4.4 Test fails

I have a test that worked in 2.4.3, but fails since 2.4.4..
Thus I assume there has been a change, but I don't know where.

It certainly has to do with ContentNegotiationConfigurer when setting a custom parameterName("_format") and using defaultContentType(MediaType.APPLICATION_JSON).

I was not able to locate the change that introduced this. Neither am I sure if the former or later outcome is the correct one. But I think the HttpMediaTypeNotAcceptableException should not be swallowed (like now in 2.4.4.)

@Configuration
public class ContentNegotiationConfiguration implements WebMvcConfigurer {
	@Override
	public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
		configurer
			.favorParameter(true)
			.parameterName("_format")
			.defaultContentType(MediaType.APPLICATION_JSON);
	}
}

@SpringBootTest
@AutoConfigureMockMvc
public class SpringBasicErrorControllerTest {
	@Autowired
	private MockMvc mvc;

	//test for '/error' servlet handler
	@Test
	public void testMediaTypeNotSupported() throws Exception {
		MvcResult rsp = mvc.perform(MockMvcRequestBuilders.get("/error?_format=test")
				.requestAttr(RequestDispatcher.ERROR_STATUS_CODE, 501))
				.andReturn();

                //fails for 2.4.4 (ex is null)
		assertTrue(rsp.getResolvedException() instanceof HttpMediaTypeNotAcceptableException);
	}
}

[bclozel]

I'm not sure this setup is valid; MockMvc is not using a real Servlet container, so error dispatches are not done in this case.

Are you testing the Error Controller provided by Spring Boot or a custom controller?
Do you still get the same error if you switch to using TestRestTemplate and a random port?

We can't think of a recent change that might provoke this, we'll need more information on this.

[membersound]

I'm testing this on the default BasicErrorController from spring-boot.
What is interesting: when using an accept http header, the HttpMediaTypeNotAcceptableException is returned as expected. Both in 2.4.3. and 2.4.4.
Thus I assume that in general the exception should always be returned, as it was in 2.4.3.

	@Test
	public void testMediaTypeNotSupported() throws Exception {
		MvcResult rsp = mvc.perform(MockMvcRequestBuilders.get("/error")
                                                .accept("test/test")
				                .requestAttr(RequestDispatcher.ERROR_STATUS_CODE, 501))
				.andReturn();

		//succeeds for both 2.4.3 and 2.4.4
		assertTrue(rsp.getResolvedException() instanceof HttpMediaTypeNotAcceptableException);
	}

[membersound]

Still no opinions on this?

[snicoll]

Unfortunately, no. It's not even clear if the issue is located in Spring Boot or Spring Framework. In the lack of a sample that reproduces the problem, and given those versions are EOL now, I am going to close this issue. I am sorry this got overlooked, and we can obviously reopen if you can share a small sample that reproduces the problem with a supported version.

[membersound]

@snicoll See working example attached, with latest spring-boot-3.1.4.

Still the problem is that MvcResult.getResolvedException() is null, which was not the case up to spring-boot-stater-parent.2.4.3! Please reopen.

HttpMediaType.zip

[snicoll]

I am trying to understand what you're trying to show and the test fails even if I remove the WebMvcConfigurer completely so I don't know if that's supposed to be related.

[membersound]

I just want to show that my test succeeds in spring-boot-starter-parent-2.4.3.

As written, the problem for junit tests is that MvcResult.getResolvedException() always resolves is null since 2.4.4 onwards, which makes it impossible to verify the exception (as it was possible until 2.4.3 where you could just call getResolvedException() and verify the exception returned from the web controller).

[bclozel]

I have tracked this down to the following change: #24539

The exception handling is now more lenient and this was done on purpose. If I understand correctly, a test was previously catching that (and actually testing the Framework behavior). I would suggest removing this assertion as a result since the behavior changed on purpose. I'm closing this issue as a result. Thanks!