fix(a11y): keep per_page fixed to prevent pagination offset regression - #296
Merged
gfargo-horizon-agent[bot] merged 2 commits intoAug 2, 2026
Conversation
When per_page shrank on the final iteration (Math.min(20, limit - postsChecked)), the server-side offset (page-1)*per_page moved backwards into already-scanned records. With limit=50 over 100 posts this caused posts 21-30 to be analyzed twice and posts 41-50 to never be analyzed. Fix: use a fixed PER_PAGE=20 constant for all requests. Client-side, break the inner post loop early once postsChecked reaches the limit, so the final page is correctly truncated without ever changing the per_page sent to the server. Regression test: mock API that honours per_page/page strictly, verifies that with limit=50 exactly 50 distinct post IDs (1-50) are analyzed and no ID from 51-100 appears in findings.
![gfargo-horizon-agent[bot]](https://avatars.githubusercontent.com/in/4083186?s=60&v=4){kind=small}
Contributor
Author
There was a problem hiding this comment.
🔎 Agent review (kiro · sonnet) — LGTM
REVIEW: LGTM
RESOLVES: full
The fix correctly pins per_page to a constant 20 and caps analysis client-side before postsChecked is incremented, eliminating both the backwards-window and the over-count bugs. The regression test's second sub-run (result2) provides solid coverage of the exact-IDs-1–50 invariant.
2 nits — 2 inline on the diff
Contributor
Author
There was a problem hiding this comment.
🔎 Agent re-review (sonnet, delta) — LGTM
REVIEW: LGTM
RESOLVES: full
The fix correctly pins per_page at 20 and truncates the final page client-side via the new inner-loop break, resolving the offset-shift bug described in OSS-1357. The added regression test validates exact-once coverage for a non-multiple-of-20 limit and all tests pass.
gfargo-horizon-agent
Bot
deleted the
agent/localpress-1357-localpress-264-b-06-a11y-pagination-offs
branch
August 2, 2026 15:51
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fix
runA11yScanpagination so every post within--limitis analyzed exactly once, regardless of whether the limit is a multiple of the page size (20).The root cause was
perPage = Math.min(20, limit - postsChecked)on line 120 ofa11y.ts. WhenpostsCheckedapproachedlimiton a final partial page,per_pageshrank (e.g. to 10) whilepagekept incrementing. Since the WordPress REST API computes its offset as(page - 1) * per_page, a smallerper_pagemoved the window backwards, causing records from an earlier page to be re-fetched. Withlimit=50over 100 posts, posts 21–30 were analyzed twice and posts 41–50 were never reached.Why
Closes #264
Plane: OSS-1357
How
Math.min(20, limit - postsChecked)with a fixedconst PER_PAGE = 20soper_pagenever changes between requests, keeping the server-side offset stable.if (postsChecked >= limit) breakguard inside the post-analysis loop to truncate the final page client-side rather than sending a smallerper_pageto the server.per_page/pagestrictly (returnsslice((page-1)*perPage, page*perPage)with accurateX-WP-TotalPages). Asserts that withlimit: 50over 100 posts,postsChecked === 50and the exact set of analyzed IDs is{1…50}— no duplicates, no posts from 51–100.Testing
bun run typecheck— clean)bun test test/unit/a11y.test.ts— 8/8 pass, including new regression test)biome check .— no issues)🤖 Generated by the harbor agent loop. Reviewed by a human before merge.
Closes #264