traceName relies on traceID to equal spanID

[terinjokes]

Description

The search result model creates a name for each trace, used by the search results page. The name is set while iterating over each result's spans, when the trace ID equals the span ID¹.

This assumption works for native Jaeger libraries. Unfortunately, if you're using Jaeger alongside Zipkin, you'll find this doesn't hold true for some Zipkin implementations, where these can differ.²

When an incoming request has no trace information attached, we generate a random trace ID and span ID. The span ID can be reused as the lower 64-bits of the trace ID, but it can also be completely different.

Most of our services using Zipkin are fronted by a service that generates (64-bit) trace IDs that match root span IDs, but there's a small handful that aren't. As a result our scatterplot occasionally shrugs a bit.

¯\_(ツ)_/¯

Steps to reproduce the issue:

1. Submit spans to a jaeger collector where the root span is started in a Zipkin implementation that generates separate random numbers for a root trace id and span id (eg, opentracing-zipkin-go) or generates 128-bit trace IDs.
2. Search for the trace in jaeger-ui.
3. Hover over a point of the scatterplot.

Describe the results you received:

¯\_(ツ)_/¯

Describe the results you expected:

A trace name made up of the root's service and operation names.

Additional information you deem important (e.g. issue happens only occasionally):

Based on my grok of the code, the traces returned in the search results are tree sorted, just like on timeline pages. Thus the first row is either the actual root, or a reasonable alternative.

If this is acceptable, I'm happy to submit a pull request changing the implementation.

¯\_(ツ)_/¯

Footnotes

1. https://github.com/jaegertracing/jaeger-ui/blob/79d262dd12e2cd64679b5d5a14aa0c7060fa85e8/src/model/search.js#L65-L68 ↩

2. http://zipkin.io/pages/instrumenting.html ↩

[yurishkuro]

This is a bug, imo. There has never been a guarantee stated that root span id == trace id. The UI should simply look for a span with parentID=0/null.

[tiffon]

@terinjokes Thanks for reporting this and for the information about spanID vs traceID of root spans.

From what I can tell, the root span is generally the first span in the data payload. But, that's reliant on the sort of the spans which is not assumed to be part of the API contract with the query service. I think @yurishkuro's suggestion of using the first span without a parent or follows-from reference as the root span will be more robust to changes in the datastore or query service.

A PR is definitely welcomed!