Skip to content

fix(api): filter /v1/sessions to active only, reduce take from 150 to 50#1415

Open
buallen wants to merge 4 commits into
slopus:mainfrom
buallen:fix/v1-sessions-active-only
Open

fix(api): filter /v1/sessions to active only, reduce take from 150 to 50#1415
buallen wants to merge 4 commits into
slopus:mainfrom
buallen:fix/v1-sessions-active-only

Conversation

@buallen

@buallen buallen commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Problem

GET /v1/sessions returns all sessions regardless of status (up to 150 records), producing a 701KB+ response body. When accessed via Cloudflare free tunnels, QUIC stalls on large response bodies, causing the mobile happy app's session list to hang indefinitely and never load.

Fix

  • Add active: true filter to the Prisma query so only active sessions are returned
  • Reduce take from 150 to 50 to further cap response size

This brings the typical response down to ~152KB, well within Cloudflare free tunnel limits.

Long-term Recommendation

Consider one of the following for a more robust solution:

  • Proper pagination: Add cursor/page params to /v1/sessions so clients can request sessions incrementally
  • Migrate to /v2/sessions/active: The existing v2 endpoint already filters to active sessions — consider updating mobile clients to use this endpoint directly

Testing

  • Before: response body ~701KB, QUIC stall on Cloudflare free tunnel, session list never loads on mobile
  • After: response body ~152KB, returns successfully through Cloudflare tunnel

🤖 Generated with Claude Code

buallen and others added 4 commits June 1, 2026 16:29
Problem: GET /v1/sessions was returning all sessions regardless of status
(up to 150 records), producing a 701KB+ response body. When accessed via
Cloudflare free tunnels, QUIC stalls on large response bodies, causing the
mobile happy app's session list to hang indefinitely and never load.

Fix: Add `active: true` filter to the Prisma query so only active sessions
are returned, and reduce `take` from 150 to 50 to further cap response size.
This brings the typical response down to ~152KB, well within Cloudflare's
free tunnel limits.

Note: A long-term solution should consider proper pagination or migrating
clients to the existing /v2/sessions/active endpoint.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant