Opened 3 years ago

Closed 22 months ago

#17938 closed enhancement (fixed)

Pagination would be useful when dealing with large numbers of results

Reported by: phranck Owned by: Frank Gregor
Priority: Low Milestone: Onionoo 3.2-1.1.0
Component: Metrics/Onionoo Version:
Severity: Minor Keywords:
Cc: irl@…, iwakeh Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm the operator of the 'cocoanaut' and 'cocoadrome' relays. Changing the filter in Globe using:

  • type=relay
  • country=Germany

and sorting by bandwidth (desc) my relay 'cocoadrome' is never be displayed. I'm providing ~8Mbit bandwidth and have 69 days of uptime (as of today).

Child Tickets

Change History (13)

comment:1 Changed 3 years ago by karsten

Status: newneeds_information

The country parameter expects a country code, not a country name, so country:de would work. And you'd use : instead of = in your query. But I'm unclear why you're not finding your relay, because I can find it by nickname. Can you give an exact query that doesn't return what you'd expect?

comment:2 Changed 3 years ago by phranck

The infos of my filter described above are not the real filter itself but the shown 'values' from the Web-UI. So in detail I used this query:

https://globe.torproject.org/#/search/query=&filters%5Btype%5D=relay&filters%5Bcountry%5D=de

Sorted by bandwidth my relay is missing. The case isn't to find it by nickname - this works as expected - but finding it by provided filter queries if you don't know the nickname.

comment:3 Changed 3 years ago by karsten

Ah, here's what happens: the search criteria are too broad and would return too many results, which is why Globe only fetches a random set of 50 results. There are currently about 300 relays from Germany, so the chances are quite high (5:1) that your relay is not included. Now, when you sort those 50 by advertised bandwidth, it just sorts those 50, rather than making another request to fetch the 50 fastest relays by advertised bandwidth. To Globe's defense, it indicates that your search is too broad: "To avoid too many requests, we limit our results to 50 items. If you want better results, try to use a search word or apply some filters."

Is this a bug or just less user-friendly than it could be? Well, it's not clearly wrong, given that there's a warning. But Globe could also fetch all results in a single request and then show them in a paginated view. I'll leave this to the Globe maintainer. (I'm just commenting from the perspective of the Onionoo maintainer, because Onionoo provides the data for Globe, and this sounded like a potential Onionoo problem, which is not the case.)

comment:4 Changed 3 years ago by karsten

Component: Metrics/GlobeMetrics/Atlas

We're shutting down Globe, so changing to the Atlas component. Admitted, Atlas doesn't have this issue yet, but if #15395 gets implemented as I suggested a week ago it may have the exact same issue. Let's only close this if we're sure we're not going to run into that issue, because it's kinda hard to debug.

comment:5 Changed 2 years ago by irl

Cc: irl@… added
Severity: TrivialMinor
Status: needs_informationnew
Summary: Unable to find my relayPagination would be useful when dealing with large numbers of results
Type: defectenhancement

See https://trac.torproject.org/projects/tor/ticket/15395#comment:10

If that is merged, we will have the issue that vague searches may result in over 500 results still, but the situation is clearly improved upon compared to the limit Globe had of only 50 results. A warning message is given and the behaviour would be as intended, so I'm making this an enhancement, not a defect.

comment:6 Changed 23 months ago by karsten

Cc: iwakeh added
Status: newneeds_review

When re-reading this ticket I realized that pagination requires displaying how many pages remain, and Onionoo does not provide that information as of now. That's why I added four new fields "relays_skipped", "relays_truncated", "bridges_skipped", and "bridges_truncated" in my Onionoo branch task-17938. Please review.

comment:7 Changed 23 months ago by iwakeh

Component: Metrics/AtlasMetrics/Onionoo

This turned into an Onionoo ticket.

A new ticket should be created for Atlas once the Onionoo part is done.

comment:8 Changed 23 months ago by iwakeh

Milestone: Onionoo 3.2-1.1.0

comment:9 in reply to:  7 Changed 23 months ago by iwakeh

Replying to iwakeh:

This turned into an Onionoo ticket.

A new ticket should be created for Atlas once the Onionoo part is done.

The new ticket for Atlas is #21186.

comment:10 Changed 22 months ago by karsten

bump. (I'm hoping to put out the next release this week, and that should ideally include this new feature.)

comment:11 Changed 22 months ago by iwakeh

Status: needs_reviewmerge_ready

Looks fine and has tests, checks and tests pass.
(Nitpicking: Shouldn't the date in the protocol coincide with the release date?)

Ready for merge.

comment:12 Changed 22 months ago by karsten

Thanks for looking! And yes, the date in the protocol should indeed be the same as the release date. I'll wait with merging until we know which date that will be.

comment:13 Changed 22 months ago by karsten

Resolution: fixed
Status: merge_readyclosed

Merged, as we're planning to put out the release today. Will deploy once there's a release. Closing. Thanks!

Note: See TracTickets for help on using tickets.