Log the response cause that is raised after a request timed out

[minwoox]

Currently, an exception that is raised after a request is timed out on the server side is silently ignored.
Because the RequestLog is complete when the timeout response is sent to the client, there's no way to record the exception.

This makes user hard to diagnose the problem. The only exception that users would see is the RequestTimeouException instead of the actual exception that may be the cause of the timeout.
So, it would be nice if we could also log the exception so that users would use it for debugging.
One possible way to do this is using UnhandledExceptionsReporter here:

armeria/core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

Line 392 in 491841f

reqCtx.logBuilder().responseCause(cause);

[trustin]

Another option could be to modify RequestLog API to allow storing more than one request/response exceptions.

[coderclcl]

Let me try this one~! 🚀

[ikhoon]

Another option could be to modify RequestLog API to allow storing more than one request/response exceptions.

It would be nice if we also implemented a way to notify or log the late exceptions. My concern was that causes added after RequestLog is completed may not be logged by Logging{Client,Service}.

I propose the following idea:

• Add RequestLogProperty.ADDITIONAL_RESPONSE_CAUSE is used to listen to an additional exception.
• Provide an option in LoggingClient or LoggingService to log these additional exceptions even after a request is completed.

if (shouldLogAdditionalException) {
    ctx.log().whenAvailable(RequestLogProperty.ADDITIONAL_RESPONSE_CAUSE).thenApply(log -> {
        // log the cause
        logger.warn("A late response exception occurred after the response completes. ctx: {}",
                    ctx, log.additionalResponseCause());
    });

}

[jrhee17]

I propose the following idea:

Add RequestLogProperty.ADDITIONAL_RESPONSE_CAUSE is used to listen to an additional exception.
Provide an option in LoggingClient or LoggingService to log these additional exceptions even after a request is completed.

This has already been discussed, but for the record: Another problem with the above approach is that the garbage collection timing of ctx may be ambiguous.