Opentelemetry panics on Span::follows_from with "Span to follow not found" #2399
Comments
|
I'm not sure if this is correct, but I'm pretty sure you need to enter the spans first. Creating them does nothing until you enter them, and then they are "used". |
That's not possible as entering the span takes ownership of it, so you can't call I did find that it's possible to add the link through opentelemetry directly by getting the context from the span as a temporary workaround. let span1 = tracing::span!(tracing::Level::INFO, "span_1");
let span2 = tracing::span!(tracing::Level::DEBUG, "span_2");
{
let cx = span1.context();
let span = cx.span();
let span_cx = span.span_context();
span2.add_link(span_cx.clone());
} |
|
Does this work? Here we get the ID and then enter the span. The ID should still stay valid: let span1 = tracing::span!(tracing::Level::INFO, "span_1");
let span1_id = span1.id();
let span1=span1.entered(); // Enter here, ID should still be valid
let span2 = tracing::span!(tracing::Level::DEBUG, "span_2");
span2.follows_from(span1_id); |
|
That does indeed work, thanks. Still interesting that you'd need to enter them first. |
|
You're welcome :) |
fnichol
added a commit
to systeminit/si
that referenced
this issue
Jan 26, 2024
This change incorporates an upstream fix in `tracing-opentelemetry` to prevent parent and "follows-from" span association from panicking under certain scenarios. Additionally, the strategy to determine the appropriate span for PostgreSQL and NATS transactions/subscriptions has been updated slightly. The macros present prior to this change attempted to prevent another "Mutex poisoned" issue encountered a year ago. The updated `tx_span()` and `sub_span()` functions check to see if `Span::current()` is disabled, in which case a `Span::none()` is returned, otherwise the current Span is returned. The former macros were slightly less flexible in that they checked `target` and `level` span metadata--which happened to be correct in these two cases. References: tokio-rs/tracing-opentelemetry#14 References: tokio-rs/tracing-opentelemetry#86 References: tokio-rs/tracing#2399 References: tokio-rs/tracing#1766 Signed-off-by: Fletcher Nichol <fletcher@systeminit.com>
fnichol
added a commit
to systeminit/si
that referenced
this issue
Jan 26, 2024
This change incorporates an upstream fix in `tracing-opentelemetry` to prevent parent and "follows-from" span association from panicking under certain scenarios. Additionally, the strategy to determine the appropriate span for PostgreSQL and NATS transactions/subscriptions has been updated slightly. The macros present prior to this change attempted to prevent another "Mutex poisoned" issue encountered a year ago. The updated `tx_span()` and `sub_span()` functions check to see if `Span::current()` is disabled, in which case a `Span::none()` is returned, otherwise the current Span is returned. The former macros were slightly less flexible in that they checked `target` and `level` span metadata--which happened to be correct in these two cases. References: tokio-rs/tracing-opentelemetry#14 References: tokio-rs/tracing-opentelemetry#86 References: tokio-rs/tracing#2399 References: tokio-rs/tracing#1766 Signed-off-by: Fletcher Nichol <fletcher@systeminit.com>
si-bors-ng bot
added a commit
to systeminit/si
that referenced
this issue
Jan 26, 2024
3222: chore(si-data-pg,si-data-nats): compute appropriate Span for txns/subs r=fnichol a=fnichol This change incorporates an upstream fix in `tracing-opentelemetry` to prevent parent and "follows-from" span association from panicking under certain scenarios. Additionally, the strategy to determine the appropriate span for PostgreSQL and NATS transactions/subscriptions has been updated slightly. The macros present prior to this change attempted to prevent another "Mutex poisoned" issue encountered a year ago. The updated `tx_span()` and `sub_span()` functions check to see if `Span::current()` is disabled, in which case a `Span::none()` is returned, otherwise the current Span is returned. The former macros were slightly less flexible in that they checked `target` and `level` span metadata--which happened to be correct in these two cases. References: tokio-rs/tracing-opentelemetry#14 References: tokio-rs/tracing-opentelemetry#86 References: tokio-rs/tracing#2399 References: tokio-rs/tracing#1766 Co-authored-by: Fletcher Nichol <fletcher@systeminit.com>
|
You don't need to enter the span, it just needs to exist. This is a special case of #688. When you have a span entered, you can guarantee that it exists so that's one way to go about it. Doing this will also work: tracing::trace_span!("start").in_scope(|| {
let span1 = tracing::span!(tracing::Level::INFO, "span_1");
let span2 = tracing::span!(tracing::Level::DEBUG, "span_2");
span2.follows_from(span1.clone());
}); |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
Version
Platform
Darwin C02G3240ML7J 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64
Crates
tracing-opentelemetry
Description
Using this code:
Causes this panic to occur:
The text was updated successfully, but these errors were encountered: