What happened?
Both getMaintainerPrQueue and getMaintainerIssueQueue in src/app/actions/maintainer.ts (lines 369 and 520) paginate with:
.range(page * PAGE_SIZE, (page + 1) * PAGE_SIZE * 4)
This overscan window is meant to give the client side tier resort enough rows to work with, but each page's range overlaps the next page's range instead of starting where the previous page's resorted output actually ended. Page 0 fetches rows 0 to 100, resorts, returns the top 25. Page 1 fetches rows 25 to 200, which already overlaps page 0's window, resorts again, and returns its own top 25.
Since the resort order has no fixed relationship to the underlying fetch order, this produces duplicate rows across pages and can silently skip rows that should have shown up, especially once an installation has more open PRs or issues than fit inside one overscan window.
Steps to Reproduce
- Seed an installation with more than 100 open PRs (or issues) so they span multiple overscan windows
- Page through the maintainer PR queue or issue queue
- Some rows show up on more than one page, others never show up at all
Expected Behavior
Paging through the queue should show every row exactly once, in order, with no duplicates or gaps.
Where does this occur?
Maintainer Command Center
Additional Context
Probably needs a cursor based approach (last seen id or timestamp) instead of an offset range, since the resort step makes a simple offset increment unreliable here.
What happened?
Both
getMaintainerPrQueueandgetMaintainerIssueQueueinsrc/app/actions/maintainer.ts(lines 369 and 520) paginate with:This overscan window is meant to give the client side tier resort enough rows to work with, but each page's range overlaps the next page's range instead of starting where the previous page's resorted output actually ended. Page 0 fetches rows 0 to 100, resorts, returns the top 25. Page 1 fetches rows 25 to 200, which already overlaps page 0's window, resorts again, and returns its own top 25.
Since the resort order has no fixed relationship to the underlying fetch order, this produces duplicate rows across pages and can silently skip rows that should have shown up, especially once an installation has more open PRs or issues than fit inside one overscan window.
Steps to Reproduce
Expected Behavior
Paging through the queue should show every row exactly once, in order, with no duplicates or gaps.
Where does this occur?
Maintainer Command Center
Additional Context
Probably needs a cursor based approach (last seen id or timestamp) instead of an offset range, since the resort step makes a simple offset increment unreliable here.