getsentry / sentry-java

A Sentry SDK for Java, Android and other JVM languages.
https://docs.sentry.io/
MIT License
1.14k stars 430 forks source link

Spring Boot (Webflux): many unrelated http breadcrumbs are recorded with events #1790

Open sergey-volkov-lm opened 2 years ago

sergey-volkov-lm commented 2 years ago

Platform:

IDE:

Build system:

Platform installed with:

The version of the SDK: 5.2.4


I have the following issue:

Many (tens or even ~hundred) unrelated http breadcrumbs recorded with events. These breadcrumbs are:

Steps to reproduce:

Actual result: Screenshot from actual server-running instance sentry webflux bug

Expected result: Only a couple of related http breadcrumbs are present

Personal thoughts Both SentryWebFilter & SentrySpanClientWebRequestFilter use HubAdapter, which uses static Sentry.getCurrentHub() method, which returns ThreadLocal instance of Hub.

It seems like this mechanism may not work correctly with reactive application, which serves requests on a small number of threads, and they are switched frequently.

As far as I know, there is a way of storing arbitrary request-related data in webflux:

marandaneto commented 2 years ago

cc @maciejwalkowiak

hu-chia commented 2 years ago

Based on ThreadLocal, this issue seems unsolvable.

adinauer commented 1 year ago

We have just released 6.15.0 of the Java SDK. If you're on Spring Boot 3.0.3+ you can give ThreadLocalAccessor a try.

Here's a copy of the changelog so you know what's required: Implement ThreadLocalAccessor for propagating Sentry hub with reactor / WebFlux (https://github.com/getsentry/sentry-java/pull/2570)

We've also fixed a bug for the WebFlux integration (#2580) in this release for older versions of Spring Boot and when not using context-propagation. In case you give it a try it would be great if you could give us feedback 🙏 .

adinauer commented 1 year ago

Closing this now as it should be resolved (see comment above), feel free to reopen if you run into the problem again.

adinauer commented 4 months ago

This is still an issue for our Spring Boot 2 integration.

We could take another stab at it by trying to use reactor.core.CoreSubscriber and Hooks.onEachOperator as described here. Needs testing whether this is has a lot of impact on performance.

Putting this in the backlog but can't say when we'll get to it.