Opus finding
loadCrossRepoReceipts.limit applied to mergedAt DESC NULLS LAST can include in-progress rows after the lag-aware code path
lowbugmedium
- apps/web/lib/receipts.ts:147-165
- apps/web/lib/outgoing-prs.ts:96-113
Only rows transitioned via markMerged get status='merged', and markMerged is gated on non-null mergedAt+mergeSha. So merged rows should always satisfy the non-null invariant. The mapMergedRowsToReceipts belt-and-braces filter is correct, but the limit is applied before that filter, meaning if any row ever had status='merged' with null mergedAt (e.g. manual DB edit), the page could return fewer than `limit` rows even when more valid rows exist. This is acceptable defensiveness given there's no DB CHECK constraint.
Recommendation
Optionally add a SQL-level filter `AND merged_at IS NOT NULL AND merge_sha IS NOT NULL` to loadCrossRepoReceipts so limit truncation is consistent with display filtering. Or add a CHECK constraint at the DB layer.