Skip to content

fix(ui): request answers page by page instead of 999 at once - #1573

Open
culfin wants to merge 1 commit into
apache:mainfrom
Besser-Sehen-Landshut:fix/paginate-answers-request
Open

fix(ui): request answers page by page instead of 999 at once#1573
culfin wants to merge 1 commit into
apache:mainfrom
Besser-Sehen-Landshut:fix/paginate-answers-request

Conversation

@culfin

@culfin culfin commented Aug 18, 2026

Copy link
Copy Markdown

The question page already has everything it needs to paginate: the page number comes from the URL, a useEffect reloads when it changes, and a Pagination control is rendered. Only the request ignores all of it:

const res = await getAnswers({
  question_id: qid,
  page: 1,
  page_size: 999,
});

Answers past the 999th are unreachable. The list never contains them, and since the displayed count is the length of that list, the heading claims the question has exactly 999 answers. In the forum I maintain two threads are above that limit — 13368 and 10110 answers — so roughly 22000 posts could not be reached through the UI at all.

Long questions are slow. Measured on a question with 999 answers:

time to first answer visible
ordinary question 0.2 s
999 answers 19 s

The browser parses and hydrates a thousand posts in order to show fifteen.

Proposed Changes

  • request page from the URL and ANSWER_PAGE_SIZE answers per page
  • take the total from res.count instead of the length of the current page, so the heading and the page count stay correct
  • name the page size once instead of repeating 15 in three places

One behavioural note

The list is filtered client-side to hide deleted answers that only their author and admins may see. With every answer loaded, counting the filtered list happened to give an exact total. Now the total comes from the server and can be off by the number of deleted answers on the current page. Filtering those server-side would remove the discrepancy entirely, but that looked out of scope for this fix.

Verified with prettier --check against the projects config.

The question page already has everything it needs to paginate: the page
number comes from the URL, a useEffect reloads when it changes, and a
Pagination control is rendered. Only the request ignores all of it and
asks for 999 answers in one go.

Two consequences:

Answers past the 999th are unreachable. The list never contains them,
and because the count shown is the length of that list, the heading
claims the question has 999 answers. A forum I maintain has two threads
above that limit, with 13368 and 10110 answers; roughly 22000 posts were
inaccessible through the UI.

Long questions are slow. Measured on a question with 999 answers, the
browser needs 19s before the first answer is visible, against 0.2s for
an ordinary one — it has to parse and hydrate a thousand posts to show
fifteen.

Changes:

  - request `page` from the URL and ANSWER_PAGE_SIZE per page
  - take the total from `res.count` rather than the length of the
    current page, so the heading and the page count stay correct
  - name the page size once instead of repeating 15 in three places

One behavioural note: the list is filtered client-side to hide deleted
answers that only their author and admins may see. With every answer
loaded, counting the filtered list gave an exact total. Now the total
comes from the server and can be off by the number of deleted answers
on the current page. Filtering these server-side would remove the
discrepancy, but that seemed out of scope here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant