span name selector UI broken #748
Comments
|
Is it broken or inefficient?
|
|
Regardless, will look into it now, just wondering if the UI is broken and I
somehow didn't notice!
|
|
looking now.. should have a fix shortly. thanks for keeping an eye out! |
|
ps wow.. this did happen! |
codefromthecrypt
pushed a commit
that referenced
this issue
Sep 30, 2015
The span name selector UI was calling getTraces instead of getSpanNames. This happened during the switch to the json api. This change fixes that and clarifies the confusing naming that was used in the web handlers. Fixes #748
|
ok here's the fix #749 |
codefromthecrypt
pushed a commit
that referenced
this issue
Sep 30, 2015
The span name selector UI was calling getTraces instead of getSpanNames. This happened during the switch to the json api. This change fixes that and clarifies the confusing naming that was used in the web handlers. Fixes #748
|
Pushing 1.13.3 immediately. Eta 1hr |
|
Yeah, so it was both inefficient and broken ;) Anyways, thanks for the quick fix! 👍 |
|
Raise your hand if you want test coverage on the JavaScript! |
|
:both_hands:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the merge of the json api branch, the selector in zipkin-web is broken, because it loads data from
/api/spans?serviceName=xxx(which returns a nested array of spans), and then tries to display it (as if it was a array of strings).Previously, the data was loaded from a span names endpoint, which used
getSpanNamesin the span store to retrieve a list of span names. This approach was superior, because it allows the span store to execute an efficient query to just aggregate all span names across the traces (the aggregates could even be stored separately).The text was updated successfully, but these errors were encountered: