In 2019 Week 12, some of the internal APIs for paging and cursors have changed slightly. If you don't run any custom code, you are not affected by this change (except that it fixes some bugs and improves performance slightly).

If you maintain extension code that implements Query classes with non-default orders, you may need to adjust your code. In most cases, this adjustment is trivial.

Previously, Phabricator could fail to page through objects correctly when the database contained a long sequence of broken objects (usually, 100 or more), like thousands of commits belonging to a repository which was destroyed with a manual DELETE FROM ... instead of bin/remove destroy. Fixing this issue required some structural changes to how paging works.

See T13259 for motivation. See D20291 for a technical breakdown of the internal details of the change.

In most cases, you only need to adjust things if you maintain code which implements getPagingValueMap(...) on a Query class. If you have these methods in your code:

Simple Cases: In almost all cases, transform getPagingValueMap(...) into newPagingMapFromPartialObject($object), following the examples in D20292. This should cover all cases where the object is relatively normal and paging is based on row which stores the object. Almost all paging is covered by this.

Note that the $object you are passed is a partial object that has not yet been filtered or had data attached. In particular, you can not access data attached by willFilterPage() or didFilterPage() inside newPagingMapFromPartialObject(). The viewer may also not be able to see the $object (it hasn't been filtered yet), so you shouldn't expose it to them (although this would normally be difficult, anyway).

Complex Cases: In more complex cases, you can follow the complex examples in D20293. This covers cases where paging is based on a secondary table, or some other kind of external context, or the alignment of the stars, or your table has no id column.