Describe the Bug
The daily streak detection job (streakDetect) fetches "anyone who logged XP yesterday" with a plain query that has no pagination (no .range()). Supabase caps results at 1000 rows by default. When more than 1000 activity rows occur in a day, users beyond that window are silently skipped and never receive their streak XP — with no error or log. (The follow-up events fetch below it is correctly paginated; the initial actives query is not.)
Steps to Reproduce
- Have a day where
xp_events contains more than 1000 rows in a 24-hour window.
- Wait for the
streak-detect cron to run (00:05 UTC).
- Check
xp_events for source = 'streak'.
- Observe that only the first ~1000 users were processed; the rest got no streak XP.
Expected Behavior
All active users should be scanned for streaks, or the query should paginate (like the events fetch does below it) so no user is silently dropped.
Screenshots (If applicable)
N/A
💻 Environment Details
- OS: N/A (cron/server-side)
- Browser: N/A
- Version: main
Describe the Bug
The daily streak detection job (
streakDetect) fetches "anyone who logged XP yesterday" with a plain query that has no pagination (no .range()). Supabase caps results at 1000 rows by default. When more than 1000 activity rows occur in a day, users beyond that window are silently skipped and never receive their streak XP — with no error or log. (The follow-up events fetch below it is correctly paginated; the initial actives query is not.)Steps to Reproduce
xp_eventscontains more than 1000 rows in a 24-hour window.streak-detectcron to run (00:05 UTC).xp_eventsforsource = 'streak'.Expected Behavior
All active users should be scanned for streaks, or the query should paginate (like the events fetch does below it) so no user is silently dropped.
Screenshots (If applicable)
N/A
💻 Environment Details