pagination sets next query even though there are no more results

[rakyll]

If the query contains a limit, backend keeps returning MORE_RESULTS_AFTER_LIMIT even though there are none.

var q = ds.query(['Kind']).limit(10);

We make an end cursor comparison to detect where to terminate pagination, but it costs us one extra query that returns an empty list of results.

[rakyll]

b/10688926

[stephenplusplus]

Any updates on this one? Just going through old issues :)

[rakyll]

This will never be fixed probably in the short term (I mean in 2-3 years).

[silvolu]

We could workaround this by making 2 calls the first time, one for the current page and one for the next page. If there are no results in the next page, we return null for next query. If there is another page, we store the results and return nextquery. For following queries, we would request page+1 to determine if there are still results, store the new page in memory if that's the case, return the previously stored page and return nextquery according to whether we have or not a next page.
Does it make sense?

[rakyll]

We've talked about implementing this offline, but I wonder what happens if what we cache is dirty. User will not have a way to invalidate it. It could be unexpected in many cases. I think that's why we haven't implemented it the way you've described above in the first place.

[ryanseys]

costs us one extra query that returns an empty list of results.

Sounds like a small price to pay to provide a better experience to developers

[stephenplusplus]

Our default pagination behavior has changed dramatically since this issue (almost exactly 1 year ago!). By default, we now run query after query until no results are returned. This behavior can be switched off to revert to manual pagination. But, this specific issue no longer applies to our library, and whatever is going on in "b/10688926", that's where the misleading backend behavior issue can be tracked.