Arvados

Isn't this easy enough to handle at the client level with filters like modified_at >= current_working_modified_time, uuid not in [list of UUIDs I've already seen with that modified time]?

The goal here is to provide a safe and easy way for a client to get the next page of results. Note-3 is safe but not easy. Ensuring modified_at uniqueness helps make the "modified_at >= X" method safe, but even that is a bit awkward.

In order for "sort by modified_at" to be completely safe, we must guarantee at the database level that modified_at is not only unique, but greater than all other rows' modified_at values at the time of insert/update. Currently, modified_at is assigned by Rails model validations and (AFAIK) there is nothing in place to prevent updates from getting reordered between "assign modified_at" and "insert/update database record". I think it's a good idea to enforce this constraint.

An even better solution would be for the server to provide a "next page token" which the client can send with its next request. This way the "next page" logic can sit on the server side instead of the client side, and the client doesn't need to know exactly which ordering guarantees are enforced. It can stick to "if the server doesn't give me a safe next-page link, I can't work."