[Bug]: Backwards rendering of CHILD_OF vs. FOLLOWS_FROM

[shaun-cox]

What happened?

When creating a new span with a single link to a followed span in the same trace, the UI renders the new span as if the followed span were actually the parent span, and renders a link icon for the true parent of the new span. In other words, the UI seems to flip the meaning of CHILD_OF and FOLLOWS_FROM when rendering, even though the references are correctly expressed in the trace.

Steps to reproduce

1. Create a new trace with two immediate child spans logically referred to as followed and parent
2. Create a third span as a child of parent and specify one link to the followed span
3. View the trace and note that the third span is rendered as a child of followed with a link to parent instead of the other way round.

Expected behavior

I expected child spans to be rendered beneath their parent, not beneath a linked span.

Relevant log output

No response

Screenshot

Additional context

Hopefully the annotated screen shot depicts the issue clearly.

The red-circled span shows a parent spanID ending in dc34 and a follows-from spanId ending in de6f. Yet the red-circled span named remote_client::send_response is rendered as if the parent is the follows-from span of de6f.

Jaeger backend version

v1.49.0

SDK

https://crates.io/crates/opentelemetry_sdk

OTEL Rust SDK -> [OTLP] -> Jaeger-all-in-one

Pipeline

OTEL Rust SDK -> OTLP -> Jaeger-all-in-one

    // export OTEL_EXPORTER_OTLP_ENDPOINT=http://172.17.0.3:4317
    // where IP is that of jaeger container for docker inspect network bridge
    let _tracer = opentelemetry_otlp::new_pipeline()
        .tracing()
        .with_exporter(opentelemetry_otlp::new_exporter().tonic())
        .with_trace_config(config().with_resource(Resource::new(service_attributes(service_name))))
        .install_batch(opentelemetry_sdk::runtime::TokioCurrentThread)?;

Stogage backend

Jaeger all-in-one

Operating system

Linux

Deployment model

Docker

Deployment configs

No response

[yurishkuro]

typically child-of should take precedence over follows-from links.

[shaun-cox]

@yurishkuro, I would consider making a PR with a fix if I could get a rough pointer into the code base where the adjustments are most likely to be needed. (I'm just completely unfamiliar with this codebase.)

[yurishkuro]

Unfortunately, I am not that intimately familiar with the UI code either. My typical approach is to look at some UI labels in the screen of interest, find them in the code, and walk upwards. In theory, there can be several solutions to this problem:

• UI might make random decision about a proper parent
• UI might always assume the first reference as the parent, but then introduce a re-ordering somewhere else in the code
• UI might 100% respect the ordering, but not alter it itself, instead relying on the server (which I think already ensures child-of refs come first)