Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing logs in case of errors #2053

Open
oemergenc opened this issue Mar 23, 2025 · 1 comment
Open

Missing logs in case of errors #2053

oemergenc opened this issue Mar 23, 2025 · 1 comment
Labels

Comments

@oemergenc
Copy link

Hi,

I have a spring webflux application with a simple Controller like this, this is just for demonstration purposes:

@RestController
open class ErrorController {

    @GetMapping("/abort")
    fun simulateAbort(): Mono<String> {
        logger.info { "Received connection abort simulation request" }
        return Mono.error(RuntimeException("Connection aborted"))
    }
}

I have setup Logbook in this application. Unfortunately I am missing logs for this endpoint. I have read that Error dispatch is not supported. Not sure if this means that errors are not supported.
However, I am wondering what would be the best approach to also get Logbook logs in these cases?

@oemergenc oemergenc changed the title Missing access logs in case of erros Missing logs in case of errors Mar 23, 2025
@oemergenc
Copy link
Author

ping 😃

kasmarian added a commit that referenced this issue Apr 14, 2025
…y's pipeline

Relates to #2053, #1555

LogbookServerHandler's channelRead() method is expecting to be invoked at least once with message object that is instance of `io.netty.handler.codec.http.LastHttpContent`. This happens when the handler is added using addHandlerLast(), which positioned it too late in the pipeline. By that point, other handlers (like content aggregators) had already consumed the LastHttpContent messages. When LogbookServerHandler was positioned incorrectly, it only saw the write() events but missed the complete read() events.
                                                                                                This change proposes to position the LogbookServerHandler in the pipeline at the point when the message is readable and bufferable, but before handlers that may skip lead to skipping the pipeline calls for the last closing message.

The solution also offers the following order of checks as none of the netty handlers that the solution relies on are mandatory:

First priority: After HttpTrafficHandler (where HTTP messages are fully decoded but not yet consumed)
                                                                                                 Second priority: After HttpCodec (when HttpTrafficHandler isn't available)
                                                                                                 Last resort: At the end of the pipeline
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant