-
Notifications
You must be signed in to change notification settings - Fork 38.1k
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
Tracing propagation issue in kotlin webflux / mongo in SB 3.2.1 #31893
Comments
@antechrestos Have you tried with Spring Boot 3.2.1, several issues have been fixed. Also the project is probably private as it's a 404 for me. |
@bclozel it is in spring boot 3.2.1 unfortunately (see my sample project). I updated the description to tell so |
@antechrestos Can you please make the project public as asked by @bclozel? I can't access it. |
@sdeleuze my bad. I switched it to public. |
I can now access, thanks. I see the following error after
Am I expected to customize something? |
@sdeleuze hmm the infrastructure docker compose is here to provide mongo, otel collector, tempo and grafana. I have no issue on Ubuntu. What is your os? |
@sdeleuze I've pushed one commit on each branch |
Ok I can now make your sample working thanks. I am wondering if that's not a duplicate of micrometer-metrics/tracing#174. Do you see something indicating that the issue is on Spring Framework side? |
@sdeleuze thaht's an interesting question; I've just pushed a branch where I switch back to springboot 3.1.5 and the example works (see Logs with SB 3.1.5
|
Should maybe try to run with SB 3.1.5 and forcing micrometer version used by SB3.2.1 🤔 ? |
Spring Framework 6.1 now has dedicated support for Coroutine context, so Micrometer may have to adapt. I suspect it was half-working with SB 3.1, see micrometer-metrics/tracing#243, looks and micrometer-metrics/tracing#174. We need to move forward on Micrometer side to know what to do here I think. |
It did not work in SB 3.0.0 but started to work after some versions (I don't remember which) and at somepoint I had different behaviour between brave and otel tracing... From what I see, things are quite moving fast on both SB and micrometer and, as you pointed that Spring Framework has dedicated support for Coroutine context, we should understand what is lacking today as something new without digging too far. In the current issue, what is funny is the logs
We see that traceId and span id are still present after returning from In my case I use
I don't understand everything yet we see some scope closed, the changed one have no tracing info. |
Thanks for your feedback, everything I see here points toward a lack of proper Coroutines support in Micrometer. Your comment related to In any case, let's continue the discussion on micrometer-metrics/tracing#174. Happy to fix what need to fixed on Spring side if you find something actionable on our side, but so far, that's not obvious. |
@sdeleuze I still had this issue with SB 3.2.2 . Your comment about @Bean
@ConditionalOnProperty("management.tracing.enabled", havingValue = "true")
@Order(Ordered.LOWEST_PRECEDENCE - 2)
fun addMdcContextFilter(observationRegistry: ObservationRegistry): CoWebFilter = object : CoWebFilter() {
override suspend fun filter(exchange: ServerWebExchange, chain: CoWebFilterChain) {
withContext(MDCContext()) {
chain.filter(exchange)
}
}
} and it solved my problem. I know it is not a proper solution, but it works. I wonder when I see the code in if (isSuspendingFunction) {
Object coroutineContext = exchange.getAttribute(COROUTINE_CONTEXT_ATTRIBUTE);
if (coroutineContext == null) {
return CoroutinesUtils.invokeSuspendingFunction(method, target, args);
}
else {
return CoroutinesUtils.invokeSuspendingFunction((CoroutineContext) coroutineContext, method, target, args);
}
} whether a context should not be put in attribute if it is thanks anyway |
@antechrestos Maybe, let's continue the discussion here. |
Since springboot 3.2 (still present in
3.2.1
) there is an issue with kotlin project.I made a sample project that illustrates very well the issue
main
is in kotlinjava
is the same in javaI have a typical
RestController
that log before calling repository and log after the repository.Kotlin
Controller
Repository
Logs
Java
Controller
Repository
Logs
Somehow the context gets process.
If there is any need of more information, I would be glad to help.
Maybe linked to #31877
The text was updated successfully, but these errors were encountered: