[sentry-junior]

Follow-up to #1625. This fixes two things before paginate()'s cursors ship in a release.

Overfetching on the last page. paginate() used 100-row pages for any --limit over 100. So --limit 201 made three requests of 100 and threw away 99 rows. A fresh walk now uses the same, minimal number of requests and splits the limit evenly across them: 201 → 3 × 67, 250 → 3 × 84, 101 → 2 × 51. A property test checks the request count (ceil(limit / 100)) and that a walk overfetches by less than one row per request.

Cursors that work across CLI versions. #1625 returned CLI-only cli1~<perPage>~<skip>~<server cursor> cursors. Older CLIs send any cursor straight to the API, so they couldn't use those, and the new CLI couldn't trust the raw cursors older CLIs stored. Now every cursor paginate() returns is a Sentry cursor:

• Page boundary: the server's cursor, unchanged.
• Mid-page: the cursor of the partly returned page, with the number of rows already returned written in binary into is_prev. After a leading 0, a 1 bit is _0 and a 0 bit is 0, most significant first. So 84:2:0_00_000_00 means page 84:2:0, skip 82 (0b1010010), and the worst case is about 15 characters.
  • Sentry parses is_prev with Python's int() (Cursor.from_string in src/sentry/utils/cursors.py). int() allows single underscores between digits (PEP 515), so every such string is 0, and every endpoint accepts it as a normal next-page cursor.
  • paginate() refetches the page and skips those rows. An older CLI, or anything else that sends the cursor as is, sees those rows again but never misses any.
  • encodeSkip() documents the format.
• Cursors that can't carry a skip: a server cursor that isn't a Sentry next-page cursor (e.g. a pasted is_prev=1 cursor) is returned as is. Resuming refetches that page.
• Page size: no longer stored in the cursor. OffsetPaginator cursors (<per_page>:<page>:<is_prev>) already encode it, so paginate() reads it back, and pasted or stored raw cursors resume with the right window. Other paginators (BasePaginator, GenericOffsetPaginator, SequencePaginator) treat offset as a row offset and take any page size. When resuming mid-page, the first request also fetches the rows to skip, so it uses as few requests as possible.

Because both directions work, stored -c next history is shared across versions again: no namespacing, and nothing is discarded on upgrade or downgrade. Cursors stored by older CLIs are raw server cursors and resume correctly. cli1~ cursors saved by nightly builds since #1625 are still read but never written. A damaged one is ignored with a warning, and the walk starts from the first page.

Known limit: an older CLI that sends a page-number cursor with a different --limit still misreads it. That's the pre-#1625 bug, and this PR can't fix it on the old side.

Tests:

• Properties over ports of OffsetPaginator, GenericOffsetPaginator, and a server that ignores per_page. They check that every row comes back exactly once across -c next with changing limits, that every returned cursor is a Sentry cursor (with is_prev a Python int literal equal to 0) that the API resumes from without skipping a row, and that a pasted page-number cursor resumes without skipping.
• Unit tests for the request sequences, encoded skips, cursors that can't carry a skip, and nightly cli1~ cursors.
• I checked the encoding against real Python int() for skips from 1 to 1000.

Local checks: tsc and lint pass. CLI unit suite: 11,300 pass. The only failures are 6 chmod/permission tests (completions, code-scanner, file-changes, telemetry, upgrade) that also fail on clean main in this sandbox.

via BYK.

--

View Junior Session in Sentry

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Oct 23, 2026 10:49pm UTC

[cursor]

Stale Bugbot comment from a previous run.

[BYK]

Would it be possible to make our new cursor format somehow compatible with the old one? And also this new version being able to "salvage" the old cursors? I'm guessing they are just raw cursor from the server so we should be able to do something with them? You might be able to find more tricks/hacks by looking at getsentry/sentry code

[BYK]

Wow, so this means we can have up to 99 extra 0s there? 🤣 - I think its fine and clever but if you can think of a better way, I'd definitely take it.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f9333f0. Configure here.}