Provide single parameter that accepts all other parameters as qualified search terms

This works: https://onionoo.torproject.org/details?limit=1

This does not: https://onionoo.torproject.org/details?search=limit:1

I'd like to give Relay Search users the ability to load larger results sets as long as they have explicitly asked for them. This would mean adding a limit:N to the search term as part of the search query which could be built using #23782 (moved).

Unfortunately, this parameter does not seem to work.

added component::metrics/onionoo owner::metrics-team parent::25274 priority::medium severity::normal status::reopened type::enhancement labels

The url you used above means that 'limit' was a field to search the content of, which correctly results in an error as 'limit' is no field known to onionoo.

I think you want the result you get from the following url: https://onionoo.torproject.org/details?search=xyz&limit=3

PS: 'limit' is a parameter on its own, not part of the search parameters.

The semantics of it aren't great, but it does help to keep the query as a single string in Relay Search. If breaking the semantics is a terrible idea for an internal Onionoo reason then this could be implemented by parsing the query string in Relay Search and then constructing the Onionoo query with the limit parameter but that state would then be discarded if the search was re-run. Or I could just leave Relay Search with a hardcoded maximum result set size of 2000.

The largest sensible query I can come up with is for "country:de" which is around 1300 relays, but there may be broader queries people might want to do. Without the full result set loaded (which can take a while, but it's ok if it's been explicitly requested) the sorting is not meaningful as relays were excluded from the result set.

Relay Search should keep track of the state of the limit parameter. The Onionoo syntax would be broken with such a change. Thus, I don't think that this would be an acceptable feature request either.

Closing as 'not a bug'.

Trac:
Status: new to closed
Resolution: N/A to not a bug

So, it's true that "limit" is not a valid qualified search term. Here's the relevant specification part:

Qualified search terms have the form "key:value" (without double quotes) with "key" being one of the parameters listed here except for "search", "fingerprint", "order", "limit", "offset", and "fields", and "value" being the string that will internally be passed to that parameter.

Regarding the stated use case, how about you simply omit the "limit" parameter and risk receiving thousands of documents back? We're in a much better position today to handle the load than we were a few years back.

But let's also discuss whether we want to accept the "limit" parameter as qualified search term (and the other 5 that are currently disallowed). Basically, we'd provide two different interfaces: separate parameters and a single parameter. I see how the latter would be easier to use for applications like Relay Search.

Temporarily re-opening until we're clear what we want here.

Trac:
Status: closed to reopened
Resolution: not a bug to N/A

So, this ticket is not a defect: "limit" is not a valid qualified search term. I'm rephrasing the summary to turn this ticket into an enhancement. We can still discuss how to implement this:

• by extending the "search" parameter (requires major protocol change),
• by introducing a new "super-search" parameter (with a better name),
• by using the resource string for searches (as suggested in #25274 (moved); now a parent ticket), or
• by discarding this idea because we don't really need it anymore.

Trac:
Summary: Search parameter limit always returns 400 error to Provide single parameter that accepts all other parameters as qualified search terms
Parent: N/A to #25274 (moved)
Type: defect to enhancement