source: Klonkt/src/services/ActivityPubService.js@ 8455dac

De outbox bladert nu echt door (shaer-sk4)

Wat er stond was geen paginering maar een KAP: de route haalde twintig posts uit
SQL en hield daar twintig items van over. Alles daarvoor lag niet op een volgende
pagina maar was helemaal onbereikbaar -- ook voor een lezer die netjes next
volgt.

DE MOEILIJKHEID, en waarom dit niet met een tweede slice kon: de outbox mengt
twee bronnen, posts en open tracks, gevlochten op datum. Met twee losse queries
en een offset per tabel weet je niet hoeveel van elk er in pagina drie horen.
outboxSlice doet daarom een UNION met de datum als sleutel, zet de LIMIT/OFFSET
daaroverheen, en haalt pas dan de rijen zelf op -- twee kleine queries voor de
ids van die ene pagina.

De fans-only voorwaarde zit in de UNION, dus de telling klopt per lezer: een
vreemde ziet 50 en een vriend 51, en niet allebei hetzelfde getal met een andere
lijst eronder.

pagedCollection kent nu alGesneden. Zonder dat zou een volle pagina zichzelf
als de enige zien -- hij telt het aantal pagina's uit de LIJST, en die is bij
SQL-paginering precies een pagina lang. Nu telt hij uit totalItems en biedt hij
een next zolang er meer is.

TWEE DINGEN DIE IK BIJNA VERKEERD DEED. outboxSlice en PAGINA_GROOTTE stonden
niet in de DEFAULT export, en de routes importeren AP zo -- dan is het undefined
bij het VERZOEK, niet bij het importeren. Nagelopen op de server: function,
number. En mijn eigen testdata maakte "2026-01-45" voor de 45e post; dat is geen
datum, en toISOString viel er terecht over om.

Zes tests, waaronder de kern: opeenvolgende pagina's overlappen niet en laten
niets vallen -- drie pagina's dekken alle 50, en niets twee keer.

Co-Authored-By: Claude Opus 5 <noreply@…>