Start param can give "no bugs found" when batch mutates

Bug #74983 reported by Tollef Fog Heen
10
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

If many bugs are closed for a bug query, you can suddenly end up with "No bugs found" since your offset is off.

An example is https://launchpad.net/people/ubuntu-archive/+subscribedbugs?start=150 (now; we sometimes have more than 150 bugs open, in which case you'll see bugs listed there, in which case just bumping the number to 500 or so should give the error message).

Tags: lp-bugs
Changed in malone:
status: Unconfirmed → Confirmed
Revision history for this message
Curtis Hovey (sinzui) wrote :

This does happen and it is very confusing. I do not think there is anything that can be done in Launchpad code to address this.

summary: - start can give "no bugs found"
+ Hacked start param can give "no bugs found"
summary: - Hacked start param can give "no bugs found"
+ Start param can give "no bugs found" when batch mutates
Changed in launchpad:
status: Confirmed → Won't Fix
Revision history for this message
KarlGoetz (kgoetz) wrote :

Hi Curtis,
I'm interested to know why this can't be fixed. This bugs OP appears to be fixed here, but #99738 was closed as a dupe of this bug. Has it been fixed too? Its nothing to do with hacking parameters - its to do with getting work done.
kk

Revision history for this message
Curtis Hovey (sinzui) wrote :

This issue is about mutating batches. The next link is active because at the time of your page request, there is another set. This page is effectively a cached state of Launchpad for a specific moment. Then someone changes the set (closes bugs or unsubscribed) so that there is no longer another batch. All users who request the next next batch from a cached page get the odd experience.

Revision history for this message
Robert Collins (lifeless) wrote :

Would it make sense to shift the start to end-batch_size, when start >= end ? That way, if someone encounters an end-of-collection event, they will see a page with bugs on it, and disbaled next buttons.

Revision history for this message
Curtis Hovey (sinzui) wrote :

There are some difficulties with this suggestion. The BatchNavigator is a blackbox. It would be deciding to change the users request, but the view that generates the page does no know that batch is not what the user asked for. This would be very confusing. The user will probably be seeing many of the same bugs before, but may not realise it until looking at a few.

The underlying issue here is that links set user expectations. The page should state what it contains, and in an odd case like this issue, it needs to explain why it does not contain something. Pages that use batches could adjust the message when there is nothing to show and the batch is greater than: X does not have more than y items. The batch may have changed while you were looking at the previous page. See the _start of the batch_.

Revision history for this message
Robert Collins (lifeless) wrote :

Sounds like there are some things we can do, reopenning accordingly.

Changed in launchpad:
status: Won't Fix → Triaged
importance: Undecided → Low
Revision history for this message
Martin Pool (mbp) wrote :

For interest, gmail's behaviour here is to send you a redirect back to the last actually existing page of the batch. That seems very elegant. If somebody keeps removing bugs as fast as you reload you will eventually get back to start=0 and it will then accurately say "no bugs found".

Try eg https://mail.google.com/mail/?shva=1#inbox/p9999

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.