fix(leaderboard): page through daily_breakdowns so wide date ranges don't drop users - #95
Closed
yoominho91 wants to merge 1 commit into
Closed
fix(leaderboard): page through daily_breakdowns so wide date ranges don't drop users#95yoominho91 wants to merge 1 commit into
yoominho91 wants to merge 1 commit into
Conversation
…on't drop users `getLeaderboardByDateRange` fetches every matching daily row in one call with `.limit(50000)`. PostgREST caps rows server-side (`db-max-rows`), so that limit is silently truncated on wider windows. Truncation isn't a partial total. A submission whose rows fall past the cut ends up with zero daily rows and is skipped by the `filteredDaily.length === 0` guard, so the user vanishes from the board entirely. And with no `.order()`, which submissions survive is arbitrary. The visible symptom is that widening the window *shrinks* the board: from=2026-07-18&to=2026-07-31 (14d) → 100 rows from=2026-07-01&to=2026-07-31 (31d) → 52 rows, bottom entry $13.40 Accounts with five figures of spend are missing from the 31d board while $13 entries are present, which is consistent with a row cap hit partway through rather than with ranking. Page through with a stable order instead. Bounded at 200 pages (200k rows) so a pathological range can't spin.
|
@yoo-minho is attempting to deploy a commit to the sculpt Team on Vercel. A member of the Team first needs to authorize it. |
Author
|
Closing — reopened from my personal account as #97 (same commit, same diff). This one was opened from a work account by mistake. Sorry for the noise. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Widening the date filter makes the leaderboard smaller, and high-spend accounts disappear from it.
Repro
?from=2026-07-18&to=2026-07-31(14d)?from=2026-07-01&to=2026-07-31(31d)Accounts with five figures of spend in that window are absent from the 31d board while $13 entries are present. A wider window returning fewer rows, with big spenders missing and tiny ones kept, does not look like ranking.
Cause
getLeaderboardByDateRangepulls every matching daily row in one call:PostgREST caps rows server-side (
db-max-rows), so.limit(50000)is silently truncated once the window is wide enough to exceed it.Truncation is not a partial total. A submission whose rows land past the cut ends up with zero daily rows, and the loop below skips it:
so the user drops off the board entirely rather than showing a smaller number. There is also no
.order(), so which submissions survive the cut is arbitrary.Row count scales with window width × submissions, which is why 7d and 14d look fine and 30d does not.
Fix
Page through with a stable order (
submission_id,date), bounded at 200 pages (200k rows) so a pathological range cannot spin.Aggregating in the DB (an RPC that returns
SUM(...) GROUP BY submission_idfor the window) would be the leaner long-term shape since it avoids shipping every daily row to the client at all — happy to follow up with that if you prefer it, but this keeps the change contained to the bug.Checks
pnpm exec tsc --noEmit: 14 pre-existing errors onmain, still 14 after — none in the touched file.pnpm build: compiles successfully. Page-data collection fails on bothmainand this branch without Supabase env vars (different route each run), so unrelated to this change.