Repository navigation
fix(recommendations): list endpoint is unpaginated and exceeds the 6 MB Lambda response cap #723
Description
Summary
GET /api/recommendations returns the full recommendation cache with no pagination or compression, including the large details blobs. On Lambda the response exceeds the 6 MB payload cap at roughly 4,000 to 6,000 rows, and the page then fails with 502 for all users.
Where
At commit b50ca38:
internal/api/handler_recommendations.go:83-118,198-237internal/scheduler/scheduler.go:1093-1138
Failure scenario
An organization with enough accounts accumulates 4-6k cached recommendations. The list endpoint response passes 6 MB, Lambda returns 502, and the recommendations page is unusable for every user. The row threshold is an estimate from the review; not reproduced live.
Suggested fix
Add keyset pagination, drop details from list responses (fetch on demand), and gzip the response.
Severity
High: a data-size threshold takes the main recommendations page down for all users.
Related: #120 (covers only the memory angle).
Reviewer ID: COR-04 (ops H8)
Found by the 2026-10-08 review fleet.
Activity
cristim commentedon Oct 9, 2026
PR #775 gzips large JSON responses on Lambda (raises the 6 MB ceiling, does not bound it). Pagination and slimmer rows are tracked in #777, so #723 stays open until that lands.
fix(server): gzip large JSON API responses on Lambda (#775)
IAmJSD commentedon Oct 16, 2026
Claiming: working on this
fix(api): cap recommendation pages by serialized bytes and reject emp…
fix(api): reject duplicate recommendation IDs when paging and documen…
fix(api): add opt-in in-memory cursor pagination to GET /api/recommen…
perf(api): page recommendations from an ID-ordered keyset scan instea…
IAmJSD commentedon Oct 27, 2026
Status update (2026-10-27, checked against main at 7b86e38): Waiting on an owner decision.
Gzip (#775), opt-in cursor paging (#974) and the SQL keyset scan (#1240) are on main. The frontend never sends limit, so it still takes the unbounded path, and list rows still carry details. #981 looks satisfied by #1240 and can probably be closed.
Left / blocked on: Waits on the #777 decision. Owner question: should the frontend follow the recommendations cursor now (getRecommendations sends limit=1000 and follows next_cursor) as the fix for the 6 MB 502, with server-side paging and slimmer rows deferred to the recommendations UI rework? Recommended answer: yes. The client change is in frontend/src/api/recommendations.ts (cristim's area unless the owner asks us). Dropping details needs samePurchaseVariantIdentity's fields promoted first.