Commit 64ca9a6
authored
fix(waterfall): Relax "next_trace" lookup to just the trace id (#104047)
For the "Next Trace" button, we'd previously, search for spans matching
the exact trace and span id of the current trace root span. However, in
some cases, the product considers another span the trace root span than
our SDK. An example is a web vital (INP) span, which happened slightly
before the navigation span started but was only added by the SDK
retroactively. In the product, we consider the web vital span the trace
root, while in the SDK we assigned the previous_trace span link to the
navigation span.
To still correctly find the next trace span, this PR now relaxes the
search criteria for the next trace, to search for a span with the
`previous_trace` attribute containing the current trace's traceId, but
_any_ spanId. This works well as long as there's only one
`previous_trace` span link per trace. If there are multiple, we'd take
the first one, which also isn't the end of the world. However, in the
SDK, we make sure to only set the link once per trace. => I think this
works well enough.
h/t @bcoe for the "contains" idea 🙏1 parent 105f121 commit 64ca9a6
File tree
1 file changed
+6
-6
lines changed1 file changed
+6
-6
lines changedLines changed: 6 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
30 | 30 | | |
31 | 31 | | |
32 | 32 | | |
33 | | - | |
34 | 33 | | |
35 | 34 | | |
36 | 35 | | |
| |||
39 | 38 | | |
40 | 39 | | |
41 | 40 | | |
42 | | - | |
43 | 41 | | |
44 | 42 | | |
45 | 43 | | |
| |||
49 | 47 | | |
50 | 48 | | |
51 | 49 | | |
52 | | - | |
53 | | - | |
54 | 50 | | |
55 | 51 | | |
56 | 52 | | |
| |||
74 | 70 | | |
75 | 71 | | |
76 | 72 | | |
77 | | - | |
78 | 73 | | |
79 | 74 | | |
80 | 75 | | |
| |||
84 | 79 | | |
85 | 80 | | |
86 | 81 | | |
87 | | - | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
88 | 88 | | |
89 | 89 | | |
90 | 90 | | |
| |||
0 commit comments