Filed from the second-wave repository audit (issue 44/100). See the audit summary for full category context.
- Location:
backend/src/controllers/stream.controller.ts:592-626 (getUserStreamSummary), backend/src/controllers/sse.controller.ts:51-54 (subscribe)
- Problem: Both fetch all of a wallet's streams via
findMany with no take/limit — getUserStreamSummary then runs an unbounded per-stream claimable-amount computation loop on every cache-miss, and subscribe re-runs the same unbounded query on every SSE (re)connection, which happens frequently on network blips.
- Evidence: Neither
findMany call includes take/cursor pagination.
- Suggested implementation: Add a reasonable
take cap (with a documented "power user" pagination path if needed) to both queries.
- Acceptance criteria: Both endpoints/handlers cap the number of streams fetched per call, verified by a test with a wallet owning more than the cap.
- Difficulty: S
- Expected impact: Bounds per-request cost for high-volume wallets, protecting both request latency and DB load.
backend/src/controllers/stream.controller.ts:592-626(getUserStreamSummary),backend/src/controllers/sse.controller.ts:51-54(subscribe)findManywith notake/limit —getUserStreamSummarythen runs an unbounded per-stream claimable-amount computation loop on every cache-miss, andsubscribere-runs the same unbounded query on every SSE (re)connection, which happens frequently on network blips.findManycall includestake/cursor pagination.takecap (with a documented "power user" pagination path if needed) to both queries.