sentry integration with spring webflux

[eddumelendez]

new spring boot starter module was added in #636. This is relying in spring boot 1.5.x release. My question is how sentry should be configured for apps who do not rely in servlet implementations I mean reactive apps.

[bretthoerner]

I'm guessing you'd need something like this to do Sentry.capture(throwable);?

https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-exception-handler

[jxpxxzj]

However HttpInterface still requires HttpServletRequest in its constructors, so is there anyway to build an HttpInterface or something else with ServerWebExchange?
I tried to copy all the members in HttpInterface and create my own, but it fails when marshaling (no InterfaceBinding provided, and I have no idea about injecting my implementation into SentryClient)

[bretthoerner]

No, we probably need to open up HttpInterface to be constructed in other ways. Like just a full list of the fields or something. PRs are welcome, I probably can't get to it in the short term.

[jnfeinstein]

Has WebFlux support been added? I'm seeing a number of thread-bound resources and servlet-specific behaviors in the code (early 2020).

[weekens]

Hey guys! In WebFlux we do it like this:

    @Bean
    fun sentryExceptionHandler(): ErrorWebExceptionHandler {
        // Sentry DSN is taken from SENTRY_DSN environment variable.
        // If it is not defined, a client becomes no-op and does not
        // consume resources.
        val sentryClient = SentryClientFactory.sentryClient()
        sentryClient.release = appVersion

        return ErrorWebExceptionHandler { _, ex ->
            // Message is sent asynchronously using inner thread pool.
            sentryClient.sendException(ex)

            Mono.error(ex)
        }
    }

[jnfeinstein]

@weekens I don't think you're capturing the HTTP properties.

[weekens]

@jnfeinstein Yeah, you're right. The first parameter (_) in lambda is actually an HTTP exchange object, all HTTP properties can be taken from there. I just didn't figure out, where to put them in sentryClient.

[pulse00]

@bruno-garcia thanks for merging #838 .

@bretthoerner I'll be working on springwebflux integration next because we need this in our projects. If it's possible to have generic-enough support for webflux / project reactor, i'll open another PR with it - would you be interested?

If yes - does your team have any ideas so far regarding webflux support? I've a couple of approaches in my local fork, but i'm not quite happy so far.

[marandaneto]

hey @pulse00 thanks for your contributions :)

I believe we don't have any work going on for webflux/project reactor.
not sure if @bruno-garcia has something in mind, otherwise PRs are welcome.

would you like to point us to these approaches so we can have a look at it? like a short description or even linking to the classes in your fork would be enough. thanks!

[marandaneto]

@jnfeinstein Yeah, you're right. The first parameter (_) in lambda is actually an HTTP exchange object, all HTTP properties can be taken from there. I just didn't figure out, where to put them in sentryClient.

just a small workaround would be instead of sending a "throwable", you could build a custom event with all the necessary params and attach the throwable to it and sendEvent
https://github.com/getsentry/sentry-java/blob/master/sentry/src/main/java/io/sentry/SentryClient.java#L126

[pulse00]

would you like to point us to these approaches so we can have a look at it? like a short description or even linking to the classes in your fork would be enough. thanks!

sure - will do. would you be open to having a new maven module, something like sentry-spring-webflux ?

[pulse00]

@weekens I don't think you're capturing the HTTP properties.

yes, this is indeed the problem. The DefaultSentryClientFactory tries to register a HttpEventBuilderHelper, which will not be registered in a webflux application.

So the sentry issue created by simply calling sentry.sendException contains only the stacktrace, without any http request information, which is sub-optimal.

HttpEventBuilderHelper is incompatible with the webflux stack, since it relies on ThreadLocal to store the current request, which can not be used in a reactive environment, since it does not heave the one thread per request model from the servlet world.

A single http request can be processed on multiple threads in a reactive application. Depending on the reactive pipeline scheduler execution.

My current approach is to try to use the pipelines context as a storage for the ServerWebExchange, and somehow make a custom SpringWebFluxHttpEventBuilder give access to the pipeline context.

This is a bit tricky though, as the sentry client is in fact a singleton, and its builderHelpers would somehow need to subscribe to each http request sequence through a WebFilter or something similar.