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

[Tollef Fog Heen]

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).

[Curtis Hovey (sinzui)]

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.

[KarlGoetz (kgoetz)]

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

[Curtis Hovey (sinzui)]

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.

[Robert Collins (lifeless)]

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.

[Curtis Hovey (sinzui)]

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_.

[Robert Collins (lifeless)]

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

[Martin Pool (mbp)]

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