Skip to content

Design: complete, bounded, or say so — one pagination contract for the repo's paged reads #6622

Open
6 of 9 issues completed

Description

@dezren39

Design: complete, bounded, or say so — one pagination contract for the repo's paged reads

Design doc: files/designs/code-pagination-contract.md in the keep-the-four-repos-healthy goal workspace. Audit at origin/main 075b2de90. Filed by the design architect (pass 63, 2026-11-06).

Summary

The repo's paginated readers were each hardened one axis at a time, and the axes keep being rediscovered per site. The stuck-cursor axis was closed site by site (cold-store-reaper's repeated-token guards #2426/#1632; pkgs/id's record_pages advance checks #6505; github-backup drain's seen-cursor guard). Within two days the fleet filed eight more instances, on the axes those fixes never stated — cursor type, volume, and completeness — across five systems:

The contract

A paged read is complete, bounded, or says so. Every paginated consumer owes three things at the read site:

  1. The cursor is validated where read — type first (present-but-non-string is a malformed reply, never end-of-pages; only the protocol's terminator ends a read), progress second (the protocol's advance rule; an empty page carrying a cursor is refused where the sender cannot produce one).
  2. The volume is bounded — a page-count and/or accumulated-result bound on every loop, sized generously above any legitimate listing; breach is an error naming the listing, never a hang.
  3. Truncation is never silent — a short read either does not stop (complete pagination, or the source's own total), fails closed (safety/eligibility decisions), or marks the truncation explicitly (operator listings).

The contract is stated once; the code stays per-system (five systems, three languages, independent deploys). One shared probe matrix travels with it: non-string cursor, missing cursor, repeated cursor, empty advancing pages, fresh-token stream past the bound, a legitimate multi-page read, a full first page on a completeness read.

Decisions recorded on this issue

Phased breakdown (sub-issues of this issue)

Phases' open questions stay in the design doc (bound-as-configuration on evidence; a mechanical ratchet after the inventory; shared truncation wording) — they are not issues.

Grounding

Agent note: this is a kind/design issue from the fleet design architect. Its phases are its sub-issues; triage of the phases should record the phase structure rather than re-filing or re-scoping the contract — the pins above (cursor type refused; fail-closed-or-complete for liveness reads) are decided here.

Activity

  1. added
    epicMeta-issue grouping multiple items (org Project Type=Epic)
    kind/designA design proposal (design-architect): multi-step, phased, decision-bearing
    on Nov 6, 2026
  2. developing-today commented on Nov 6, 2026

    @developing-today
    Contributor
  3. added sub-issues on Nov 6, 2026
  4. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · design-architect pass 63 — design filed this pass

  5. added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicMeta-issue grouping multiple items (org Project Type=Epic)kind/designA design proposal (design-architect): multi-step, phased, decision-bearingqueue/queuedHas a queued task in the Supabase agent queuesource/design-architectFiled by the repo design architect jobstatus/needs-triageNot yet triaged; needs a first looktask/triageQueue packet kind: verify, reproduce, and route this item

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions