Reduce flakiness in TomcatServlet5Test.requestWithException()

[trask]

Automated attempt at fixing flakiness in io.opentelemetry.instrumentation.servlet.v5_0.tomcat.TomcatServlet5Test.requestWithException()[2].

• Source: instrumentation/servlet/servlet-5.0/library/src/test/java/io/opentelemetry/instrumentation/servlet/v5_0/tomcat/TomcatServlet5Test.java
• Flaky executions in last 7d (this test): 229
• Flaky executions in last 7d (test container): 229
• Primary failed scan: https://develocity.opentelemetry.io/s/anvud3rfqmlsa

Recent failed/flaky scans

• anvud3rfqmlsa (flaky, :instrumentation:servlet:servlet-5.0:library:test)
• e55s5qcsl44us (flaky, :instrumentation:servlet:servlet-5.0:library:test)
• peei4r4hswlfm (flaky, :instrumentation:servlet:servlet-5.0:library:test)
• e6y5tqp6qmix6 (flaky, :instrumentation:servlet:servlet-5.0:library:test)
• xwo3bxevfasbg (flaky, :instrumentation:servlet:servlet-5.0:library:test)

Flake history (per UTC day)

Day	flaky	failed	passed
2026-04-28	0	0	80
2026-04-29	99	0	42
2026-04-30	114	0	58
2026-05-01	16	0	11

Sample failure (from Develocity)

java.util.concurrent.CompletionException: io.opentelemetry.testing.internal.armeria.common.ClosedSessionException
> io.opentelemetry.testing.internal.armeria.common.ClosedSessionException: (No message provided)

Copilot diagnosis

Flaky Test Fix Diagnosis

Root cause

The FakeAsync servlet's EXCEPTION endpoint handler was missing a critical mitigation for Tomcat's connection reset behavior. When the servlet throws an exception after writing a response, Tomcat can reset the connection before the client fully receives the response body, causing the Armeria HTTP client to fail with ClosedSessionException during the aggregate().join() call.

Fix

• Added explicit PrintWriter.close() call before throwing the exception in TestServlet5.FakeAsync.EXCEPTION handler
• Applied the same Tomcat-specific mitigation that already existed in the Async.EXCEPTION handler (lines 159-164)
• The fix uses req.getClass().getName().contains("catalina") to detect Tomcat and close the writer only on that server, ensuring the response is fully flushed before the exception is thrown

Why this addresses the root cause

The explicit close() call forces Tomcat to flush and commit the response to the network before the exception propagates to the servlet container. Without this, there's a race condition where Tomcat's error handling (triggered by the exception) can reset the connection while the client is still reading the response stream, resulting in ClosedSessionException at the client side. The Async servlet already had this mitigation and was not flaky; this fix brings FakeAsync to parity.

Risks / follow-ups

• The fix is defensive and should not mask legitimate issues since it only affects test code behavior, not production instrumentation
• If legitimate connection timeouts were being masked, they would now surface as test failures with different symptoms (timeouts rather than ClosedSessionException)
• The Tomcat-specific check using class name reflection is a heuristic; if test environments change server implementations mid-test or use custom wrappers, this detection might not trigger. However, this same pattern has been stable in the Async servlet since it was introduced

---

Review the diagnosis and the diff carefully before merging - automated fixes can mask flakiness instead of addressing the root cause.

[trask]

same fix already exists here