-
-
Notifications
You must be signed in to change notification settings - Fork 427
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
Fix: Sending errors in Spring WebFlux integration. #1819
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1819 +/- ##
============================================
+ Coverage 75.51% 75.56% +0.04%
- Complexity 2239 2243 +4
============================================
Files 225 225
Lines 8001 8016 +15
Branches 846 850 +4
============================================
+ Hits 6042 6057 +15
+ Misses 1549 1544 -5
- Partials 410 415 +5
Continue to review full report at Codecov.
|
These are pretty big cons. Wouldn't this break the relationship of breadcrumbs and events from web-requests? Not to say that it's not a better/right thing to do, but it brings to question if it's worth building this integration altogether since it's still fairly broken (though possible less broken if now we have info from the wrong request appended) |
Yes, I agree this is sub-optimal. I did not find a way to make it work, but will continue investigating. |
As far as I can tell - there is no way to do it without a considerable performance hit. Sleuth integration with Reactor, initially worked in a way that scope was copied between threads, now starting from version 3.0 they recommend "manual" mode: https://docs.spring.io/spring-cloud-sleuth/docs/current-SNAPSHOT/reference/html/integrations.html#sleuth-reactor-integration There are some other solutions to this problem - mainly circulating around Reactor + MDC - but all are home-grown and each faces issues. I think having out-of-the-box solution for capturing unhandled exceptions in Webflux is useful for users, but at this stage we should not ship integration with static methods or logging statements, as every implementation seems to be risky to me. |
Following Reactor docs, the one other way to make it work, including static api and logback as a result is to add following method that will set the thread local and reset it after operator finished work: public static <T> Consumer<Signal<T>> withSentry(Consumer<T> logStatement) {
return signal -> {
if (!signal.isOnNext()) return;
IHub currentHub = Sentry.getCurrentHub();
IHub iHub = signal.getContextView().getOrDefault(SentryWebFilter.HUB_REACTOR_CONTEXT_ATTRIBUTE, null);
if (iHub != null) {
Sentry.setCurrentHub(iHub);
logStatement.accept(signal.get());
Sentry.setCurrentHub(currentHub);
} else {
logStatement.accept(signal.get());
}
};
} Then, every call to static method on Mono<Person> create(Person person) {
return Mono.delay(Duration.ofMillis(100))
.publishOn(Schedulers.boundedElastic())
.doOnEach(withSentry(s -> Sentry.captureMessage("Creating person")))
.doOnEach(withSentry(__ -> LOG.error("ERROR LOG")))
.map(__ -> person);
} We can either add it to the code base, or add to docs. I would still keep it experimental. This marks the end of my investigation :-) |
It sounds like this API is the way to go. We can document things to lead users the right path |
Just noticed the snippet u shared is missing a try/finally to undo the hub thing in the finally block if the callback throws |
ad84721
to
5f52d18
Compare
@oliverorav I played around with this for a bit during our Hackweek and created this draft PR: #2224 But as you can see it leads to quite a mess in the A way to improve on it I can think of is to somehow apply the mess using some sort of bytecode manipulation and make the right hub available without requiring the user to write the mess. This is just an idea though and not very high on our list of priorities at the moment unfortunately. |
Closing this in favor of #2546 |
📜 Description
Fix sending errors in Spring WebFlux integration.
This time, without trying to find a workaround but rather using recommended reactive/reactor way of doing things: instead of copying hub every time executing thread changes, hub is set on Reactor context, which means:
Pros:
Cons:
💡 Motivation and Context
Fixes #1790
💚 How did you test it?
Integration tests, sample project running on the side.
📝 Checklist
Only classes marked as experimental are changed.
🔮 Next steps