fix(das): validate cursor payload fields instead of returning 500

[rsnetworkinginc]

PR body — rsnetworkinginc — entrius/das-github-mirror

Branch: fix-cursor-payload-validation (in WSL Ubuntu-22.04 clone /root/dgm, commit 2c376e7, based on origin/test @ a188d3b)
Base: test
Title: fix(miners): reject unparseable cursor payloads with 400 instead of a Postgres 500

---

Bug

decodeCursor (pagination for /api/v1/miners/:githubId/pulls|issues) checks that the decoded payload's fields have the right types, but never that created_at is actually a timestamp or that number is an integer. Both values are bound to casts in the keyset WHERE clause:

AND (p.created_at, LOWER(p.repo_full_name), p.pr_number) < ($3::timestamptz, $4, $5::int)

So a cursor that is valid base64url JSON with correctly-typed fields sails through validation and blows up inside Postgres, returning 500 Internal Server Error for malformed client input:

# {"created_at":"banana","repo_full_name":"acme/repo","number":1}
GET /api/v1/miners/1/pulls?limit=50&cursor=eyJjcmVhdGVkX2F0IjoiYmFuYW5hIiwicmVwb19mdWxsX25hbWUiOiJhY21lL3JlcG8iLCJudW1iZXIiOjF9
  -> 500 (invalid input syntax for type timestamp with time zone: "banana")

# {"created_at":"2026-06-01T00:00:00.000Z","repo_full_name":"acme/repo","number":1.5}
GET /api/v1/miners/1/pulls?limit=50&cursor=eyJjcmVhdGVkX2F0IjoiMjAyNi0wNi0wMVQwMDowMDowMC4wMDBaIiwicmVwb19mdWxsX25hbWUiOiJhY21lL3JlcG8iLCJudW1iZXIiOjEuNX0
  -> 500 (invalid input syntax for type integer: "1.5")

Base64url-decoded JSON that fails the shape check already gets a clean 400 ("cursor is malformed") — these two payloads are the gap. Since 5xx is conventionally retryable, a client holding a corrupted/truncated cursor will keep re-sending a request that can never succeed instead of restarting pagination.

Fix

Tighten the malformed-cursor check in decodeCursor:

• created_at must satisfy !Number.isNaN(Date.parse(...));
• number must satisfy Number.isInteger(...) (subsumes the previous isFinite check).

Both reuse the existing BadRequestException("cursor is malformed"). No false rejections are possible: encodeCursor only ever emits toISOString() timestamps and integer pr_number/issue_number values, so every server-issued cursor still decodes — only tampered or corrupted cursors are affected.

Tests

New pagination.spec.ts (unit):

• encodeCursor → decodeCursor round-trip (incl. repo lowercasing);
• rejection of non-base64url input, missing/mistyped fields (existing behavior, now pinned);
• rejection of unparseable created_at and non-integer number (the two new cases);
• parsePaginationQuery propagates cursor validation, still returns null when neither limit nor cursor is given, and accepts a valid limit+cursor pair.

Written red-first against the current test tip: the 3 new-validation cases fail before the fix, all 8 pass after.

Local checks

• npm test — 33 passed (4 suites)
• npm run lint — clean
• npm run format:check — clean
• npm run build — clean

---

Note on cap: rsnetworkinginc already has #221 open (fetch.processor ISSUE_CLOSURE guard). Cap is 2 per the triage bot, so this is the second and last slot — do not open anything else under this account until one of the two resolves.