You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6b3c823
Browse filesBrowse the repository at this point in the historyBrowse files
fix(webapp): use composite keyset cursor for run pagination
listRunIds/listRuns order by the composite key (created_at, run_id) but
the cursor predicate cut on run_id alone. That is only sound when run_id
lexicographic order matches created_at order. When a burst of runs is
created such that the two diverge, keyset pagination both re-includes
already-returned runs (duplicates) and drops runs it should return
(skips). For bulk replay this produced duplicate runs; for the dashboard
and runs.list it could silently skip or repeat runs at page boundaries.
- Encode cursors as the composite (created_at, run_id) key
(v2_<createdAtMs>_<runId>) and cut on the matching tuple predicate
((created_at, run_id) < / > (...)). The ORDER BY is unchanged, so the
table's primary-key alignment (and query performance) is preserved.
- Cursors are server-issued opaque tokens (the SDK just echoes
pagination.next/previous back), so this needs no client update. Legacy
bare-run_id cursors decode to the old run_id-only predicate for
backwards compatibility with in-flight cursors.
- Add listRunIdsWithCursor for forward-only batch iteration (bulk
actions) so the created_at component is sourced from the same query
that orders the rows.
- ClickHouse getTaskRunsQueryBuilder now also selects
toUnixTimestamp64Milli(created_at) AS created_at_ms.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments