Arvados

Updated API server groups_controller to order on created_at time instead of uuid. This seems to have helped with the lost data. With this update, if approved, we should have all project tabs sorting on created_at time.

PS: I think sorting on modified_at time rather than created_at time more appropriate. But this may be for another day / another ticket.

At 97f3db9

I think the approach is correct here: if the sort key isn't always unique, get an overlapping page and skip the overlapping item(s). Suggestions:

• Instead of adding or subtracting 1 second from the timestamp threshold, why not just replace the < and > nextpage_operators with <= and >=?
  • This did not work (I rechecked this morning also). Hence left it as is.

• What if the last two items on page 1 have the same created_at timestamp? Doesn't that put us back in "too infinite" world? I think this can be addressed by adding a last-resort sort key ("@orders << 'uuid asc'"?) and rejecting the last page's last_uuid and everything before it from the subsequent page results. If an entire page has the same timestamp, that won't be good enough: infinite scroll will just stop. I think I could live with that for now, especially since it should be easy enough to detect and log/report. (Ultimately API server should offer a bomb-proof "next page" link, and we should just use that...)
  • I updated last_uuid to last_uuids array that keeps track of all the uuids in current page with the same created_at time as the last item and remove all of them from the next page objects. As you said, if all the objects in the next page have the same created_at time as the previous page, this will "end" scrolling. We could fix it, but I think this is simpler and probably desirable than making this code any more complex.

• This might be a moot point given the preceding comment, but @objects.reject! do ... end would be more idiomatic than each+delete.
  • I like this. I updated the code accordingly.

For the per-tab page sizes: Instead of repeating the 200 in all of those views where we don't need to override the default page size, perhaps we could leave the default alone if not local_assigns[:limit], or even do something like this in app/views/projects/_show_tab_contents.html.erb?

- data-infinite-content-params-projecttab="<%= {limit: limit, filters: filters}.to_json %>">
+ data-infinite-content-params-projecttab="<%= local_assigns.to_json %>">

• Fixed this