JerseyServerMetricsAutoConfigurationTests httpRequestsAreTimed is flaky

[wilkinsona]

#45404 has just happened for me in a local build:

io.micrometer.core.instrument.search.MeterNotFoundException: Unable to find a meter that matches all the requirements at once. Here's what was found:
   FAIL: No meter with name 'http.server.requests' was found.
   FAIL: No meters with type timer were found.
   FAIL: No meters have the required tag 'uri'.
	at app//io.micrometer.core.instrument.search.MeterNotFoundException$FromRequiredSearch.build(MeterNotFoundException.java:242)
	at app//io.micrometer.core.instrument.search.MeterNotFoundException$FromRequiredSearch.access$100(MeterNotFoundException.java:49)
	at app//io.micrometer.core.instrument.search.MeterNotFoundException.forSearch(MeterNotFoundException.java:46)
	at app//io.micrometer.core.instrument.search.RequiredSearch.lambda$getOne$1(RequiredSearch.java:197)
	at java.base@25.0.1/java.util.Optional.orElseThrow(Optional.java:403)
	at app//io.micrometer.core.instrument.search.RequiredSearch.getOne(RequiredSearch.java:197)
	at app//io.micrometer.core.instrument.search.RequiredSearch.timer(RequiredSearch.java:118)
	at app//org.springframework.boot.jersey.autoconfigure.metrics.JerseyServerMetricsAutoConfigurationTests.lambda$httpRequestsAreTimed$0(JerseyServerMetricsAutoConfigurationTests.java:88)
	at app//org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.accept(AbstractApplicationContextRunner.java:457)
	at app//org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.consumeAssertableContext(AbstractApplicationContextRunner.java:371)
	at app//org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.lambda$run$1(AbstractApplicationContextRunner.java:349)
	at app//org.springframework.boot.test.util.TestPropertyValues.lambda$applyToSystemProperties$0(TestPropertyValues.java:177)
	at app//org.springframework.boot.test.util.TestPropertyValues.applyToSystemProperties(TestPropertyValues.java:191)
	at app//org.springframework.boot.test.util.TestPropertyValues.applyToSystemProperties(TestPropertyValues.java:176)
	at app//org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.lambda$run$0(AbstractApplicationContextRunner.java:349)
	at app//org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.withContextClassLoader(AbstractApplicationContextRunner.java:377)
	at app//org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.run(AbstractApplicationContextRunner.java:348)
	at app//org.springframework.boot.jersey.autoconfigure.metrics.JerseyServerMetricsAutoConfigurationTests.httpRequestsAreTimed(JerseyServerMetricsAutoConfigurationTests.java:85)

Looking at Develocity, it's also been flaky on CI:

[wilkinsona]

We only see the flakiness on main. This is due to it using Tomcat 11 that includes this change that affects response processing and when the response is sent to the client. With that change in Tomcat 11, the response is now closed when the number of bytes written is greater than or equal to the expected content length. Closing the response allows it to be sent to the client and this is happening earlier than it did with Tomcat 10.1 and, crucially, before the timer has been registered. Sending the response before the timer has been registered initiates a race between the response being received on the client side, which causes the test to proceed and look for the timer, and the timer being registered on the server side.

The test can be made to fail reliably by configuring it with an artificially slow meter registry:

@Bean
SimpleMeterRegistry simpleMeterRegistry() {
	return new SimpleMeterRegistry() {

		@Override
		protected Timer newTimer(Id id, DistributionStatisticConfig distributionStatisticConfig,
				PauseDetector pauseDetector) {
			try {
				Thread.sleep(2500);
			}
			catch (InterruptedException ex) {
				Thread.currentThread().interrupt();
			}
			return super.newTimer(id, distributionStatisticConfig, pauseDetector);
		}

	};
}