Receive APIs: add indexed pagination for listings #2

Open
opened 2026-05-06 04:58:51 +02:00 by jesse · 0 comments
Owner

Background

Receive listing endpoints currently collect and sort all matching KV keys before slicing the response. This follow-up tracks cursor-backed listing indexes so owner and admin pages scale with large receive-link counts.

Source: Deferred from receive links fix pass after PR multi-agent code review
File: worker.js:2641, worker.js:3993
Branch: feature/receive-links-foundation

Failure mode

  • handleListMyReceives lists owner receive indexes and materializes the full result set before returning a page.
  • handleListAllReceives scans receive metadata for admin listing behavior.
  • Large tenants or admins can produce high KV read volume, high latency, and request timeouts even when callers only need one page.
  • The fix requires API pagination/index design, response cursor semantics, and UI updates.
  • Changing listing contracts during the review-fix pass would have expanded the behavioral surface beyond the identified correctness fixes.

Proposed work

  • Define stable cursor semantics for owner and admin receive listing endpoints.
  • Store or reuse sortable receive-list indexes that can be paged without full materialization.
  • Update handleListMyReceives to page directly from indexed keys.
  • Update handleListAllReceives to avoid full metadata scans for normal admin listing.
  • Preserve backward-compatible response fields where possible.
  • Update browser UI pagination behavior if cursors become visible to the client.

Acceptance

  • Tests cover first page, next page, empty page, and stale index self-healing behavior.
  • Tests assert listing handlers do not read all receive records when a small page limit is requested.
  • Existing callers still receive receives, hasMore, and cursor-compatible pagination metadata.
  • Admin and owner listing docs describe the cursor behavior.

References

  • Follow-up from feature/receive-links-foundation receive-links review fix pass.
## Background Receive listing endpoints currently collect and sort all matching KV keys before slicing the response. This follow-up tracks cursor-backed listing indexes so owner and admin pages scale with large receive-link counts. **Source:** Deferred from receive links fix pass after PR multi-agent code review **File:** `worker.js:2641`, `worker.js:3993` **Branch:** `feature/receive-links-foundation` ## Failure mode - `handleListMyReceives` lists owner receive indexes and materializes the full result set before returning a page. - `handleListAllReceives` scans receive metadata for admin listing behavior. - Large tenants or admins can produce high KV read volume, high latency, and request timeouts even when callers only need one page. ## Why deferred from receive links fix pass - The fix requires API pagination/index design, response cursor semantics, and UI updates. - Changing listing contracts during the review-fix pass would have expanded the behavioral surface beyond the identified correctness fixes. ## Proposed work - [ ] Define stable cursor semantics for owner and admin receive listing endpoints. - [ ] Store or reuse sortable receive-list indexes that can be paged without full materialization. - [ ] Update `handleListMyReceives` to page directly from indexed keys. - [ ] Update `handleListAllReceives` to avoid full metadata scans for normal admin listing. - [ ] Preserve backward-compatible response fields where possible. - [ ] Update browser UI pagination behavior if cursors become visible to the client. ## Acceptance - Tests cover first page, next page, empty page, and stale index self-healing behavior. - Tests assert listing handlers do not read all receive records when a small page limit is requested. - Existing callers still receive `receives`, `hasMore`, and cursor-compatible pagination metadata. - Admin and owner listing docs describe the cursor behavior. ## References - Follow-up from `feature/receive-links-foundation` receive-links review fix pass.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jesse/ycloud-cloudflare#2
No description provided.