Intermittent SecurityTestCase failures: Communication Error (1001) instead of 401/403 #1601

SecurityTestCase fails now and then in CI, on 3.0 and on feature branches. A request that should get an empty-body response from the server instead gets Communication Error (1001) from the Netty client:

SecurityTestCase.withLambdaUserAuthenticationAdminRoleAuthorizerAuthenticatorShouldReturnForbiddenResponse:97
expected: <Forbidden (403) - The server understood the request, but is refusing to fulfill it>
but was: <Communication Error (1001) - The connector failed to complete the communication with the server>

A rerun passes.

Occurrences

Possibly the same cause: 39498521144 on 3.0, where RedirectTestCase.stopsAfterMaxRedirects got 1001 instead of 302.

What is known

• Only fast responses with an empty body (401, 403, 302) fail. Requests answered with 200 and a body never do.
• The server logs the 401/403 as sent, so the failure is on the client side, or in how the connection is closed.
• The server framing looks right: Content-Length: 0, and the bodyless GET goes through the body.end() path.
• Not reproducible locally: 300 iterations, including with -XX:ActiveProcessorCount=1 and 2.
• 1001 comes from NettyClientCall.handleCommunicationFailure(), for an IOException while waiting for the response head. Candidates are a reused pooled connection that the server had already closed, or a close racing with the end of the response.

Diagnostics

The client logs the final IOException at FINE only, and CI doesn't enable FINE, so we can't see which step fails. A linked PR adds:

• FINE logs to the Netty client:
  • each connection opened, reused from the pool, discarded or closed
  • each request sent
  • each response head and response end received
  • each exchange failure, with the connection
• A ci-logging Maven profile, used by the CI workflow, that writes the FINE logs of the Restlet loggers to org.restlet/target/restlet-fine.log. The workflow uploads that file as an artifact when the build fails.

On the next failure, find the failing test's port in that log and follow its connection.