Rendering traces with spans containing a 'FOLLOWS_FROM' reference seems broken

[NicolasT]

Description
I have a test program for a new client library which generates traces and sends these into Jaeger. Since a couple of days, the UI fails to properly display these traces. Initially I noticed this because the search page, upon a search request, fails to load (spinner keeps spinning).

At first I suspected my client lib, but the generated traces seem fine, and the corresponding JSON is served properly to the UI.

After some more testing I believe the issue is due to a FOLLOWS_FROM span in my trace, triggering the issue. Hence I bisected jaeger (between v0.6.0 and current master), which pointed at jaegertracing/jaeger@162470d

Hence I bisected the jaeger-ui submodule (using jaeger master), which pointed at 69d84b901

Indeed, when using jaeger-ui 69d84b901^ things work fine.

I'm not familiar with the jaeger-ui codebase, but 69d84b901#diff-8a263673c6caa913587233948bfb8af2R79 (and the Error being thrown for a non-CHILD_OF reference) raises suspicion. This Error isn't propagated in the Chrome devtools console, but when setting a breakpoint, this code path is reached.

Note: all testing is done using standalone-linux, memory back-end.

Steps to reproduce the issue:

1. Create a trace with a FOLLOWS_FROM reference
2. Load the Jaeger UI
3. Click Find Traces

I'll try to create a minimal trace exposing this, and attach the corresponding JSON to the ticket.

Describe the results you received:
UI 'hangs'. Also, browsing to the /trace/<traceId> page fails to load the trace properly.

Describe the results you expected:
My trace being displayed, as older versions of jaeger-ui do.

[NicolasT]

Bisected commit is part of #53 I believe, hence referencing.

[NicolasT]

Here's the JSON serialization of a trace exposing this as served by Jaeger on the /api/traces/<traceId> resource:

{
    "data": [
        {
            "processes": {
                "p1": {
                    "serviceName": "issue115",
                    "tags": []
                }
            },
            "spans": [
                {
                    "duration": 1173,
                    "flags": 1,
                    "logs": [],
                    "operationName": "thread",
                    "processID": "p1",
                    "references": [
                        {
                            "refType": "FOLLOWS_FROM",
                            "spanID": "ea7cfaca83f0724b",
                            "traceID": "2992f2a5b5d037a8aabffd08ef384237"
                        }
                    ],
                    "spanID": "1bdf4201221bb2ac",
                    "startTime": 1509533706521220,
                    "tags": [],
                    "traceID": "2992f2a5b5d037a8aabffd08ef384237",
                    "warnings": null
                },
                {
                    "duration": 70406,
                    "flags": 1,
                    "logs": [],
                    "operationName": "demo",
                    "processID": "p1",
                    "references": [],
                    "spanID": "ea7cfaca83f0724b",
                    "startTime": 1509533706470949,
                    "tags": [],
                    "traceID": "2992f2a5b5d037a8aabffd08ef384237",
                    "warnings": null
                }
            ],
            "traceID": "2992f2a5b5d037a8aabffd08ef384237",
            "warnings": null
        }
    ],
    "errors": null,
    "limit": 0,
    "offset": 0,
    "total": 0
}

This is a trace within a single process with one 'root' span, and one more span which FOLLOWS_FROM said root. I guess it should be trivial to reproduce this scenario using whichever client library.

[tiffon]

@NicolasT Thanks for reporting and for the great info. Will see about replicating this and adding to our test cases... 👍

[NicolasT]

My original test-case (of which the trace above is just a subset) now works fine 👍

[tiffon]

Awesome. Thanks for the confirmation, @NicolasT 👍

[ledor473]

I'm having a similar issue that seems closely related to this one. I did try to update the Query component to the newest version (used the latest docker tag instead of 0.9.0 https://hub.docker.com/r/jaegertracing/jaeger-query/tags/)

As NicolasT reported, there's no error shown in the Chrome Console and the spinner keeps spinning.

Here's a JSON that should reproduce the problem: https://gist.github.com/ledor473/d5c68c6a75b8d57d80b5f65c16c5243f
This is the response from the /api/traces call.

I had to truncate a bunch of information, but I think I preserved the traceID/spanID intact.

Should I file a new issue or here is a good place to start?

[NicolasT]

@ledor473 Likely the very same issue. The jaeger-ui submodule in the jaeger repository hasn't been updated yet to include this fix, hence latest not working. You may want to test by checking out jaeger, going into jaeger-ui, checkout a ref which contains the fix, then build all-in-one and run it from console.

Or wait for the @jaegertracing devs to update the jaeger-ui submodule, that'd be really cool 😉

[black-adder]

Sorry bout this, we're trying to land a couple of new features before cutting a new version. Although in the future looks like cutting a patch every time we have a major UI update or bug fix doesn't sound like a bad idea.

[ledor473]

Sounds good!
I'll try to build a Docker image with the most recent changes and report back

[ledor473]

Thanks @NicolasT @black-adder! I can confirm the fix is working 👌