Second hotfix on top of v1.4.37. The v1.4.37.1 fire-and-forget release removed the 60 s event-loop block but live HAR still showed /api/analytics?slice=summaries taking ~3.1 s per cache miss.
Root cause
The v1.4.35 implementation read EVERY DAY rollup bucket for the user (findMany without a bucketStart window) and composed count / min / max / mean in JavaScript. On a power-user account that materialised as a ~306k-row transfer plus a JS loop. The slim slice's contract is the all-time per-type aggregate — exactly what a SQL GROUP BY type returns in a single round-trip.
Fix
computeFromRollups in src/lib/analytics/summaries-slice.ts swaps the unwindowed prisma.measurementRollup.findMany for a per-type $queryRaw GROUP BY that returns 8 rows of count / min / max / mean instead of ~306k bucket rows. The downstream JS aggregation is bypassed because the per-type aggregate is already shaped server-side.
Expected: cache-miss budget on power-user accounts drops from ~3.1 s into the < 100 ms range.
Operator notes
- No schema change. No env-var change. Response body shape unchanged.
- Coolify auto-deploys main on tag push.