bench-routes: Bug: Ping and Jitter routes not working as expected
Describe the bug
The /ping and /jitter routes do not display the charts upon selecting the routes from the input.
To Reproduce Steps to reproduce the behaviour:
- Go to
/pingor/jitter. You can navigate from Testing Tools in the sidebar menu. - Select a route from the select input.
- No charts/information is displayed.
- See error:
index.js:1451 SyntaxError: Unexpected token I in JSON at position 0in the console.
Expected behaviour The Ping/Jitter charts should be displayed for the selected route.
Screenshots
Desktop:
- OS: Ubuntu
- Version 20.04
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 17 (17 by maintainers)
I think @geforce6t is already working on this. I will let him for this issue. I haven’t gone through the PR, but there can be better possibilities than what I proposed.
@muskankhedia I was in an initial impression that doing a two-times communication with the API is not a good thing. But it turns out that UI needs to know some way which all paths are available for querying. This will require the first request and I don’t think we can avoid it.
So, as far as we fetch the updated list of all time-series (from
/get-route-time-seriesendpoint), and then fill them in the dropdown and let the user click and on click, we send the particular hash to the querier; it should be fine. It will take a lot of time only if we loop across all the time-series or response of the above endpoint. But I am under the impression that we just show that in the dropdown and ask the user to click on the one he is interested in. As long as this happens, I don’t think there would be any slower. (only time involved would be fetching the updated list of all routes from the endpoint which should be fast).I haven’t gone thought the PR yet, but I hope to do it this weekend. Thank you guys for the discussion and your patience.
@geforce6t Finding hash through looping over all routes is not the solution. That’s the same thing as fetching all the routes in frontend and matching the one with same URL. I was talking about generating the hash for the URL for which a function
URLHashis already there.But the function requires other fields also likeheader,params,method.@geforce6t Yes, the reason is completely correct. And the integer value you see is the hash value for every route.