From 3bc25509cff840696f765a1e4d6e2b331eba687b Mon Sep 17 00:00:00 2001 From: Thomas Camlong Date: Sun, 9 Aug 2026 21:42:13 +0200 Subject: [PATCH] docs(findings): record what the real Umami instance revealed about the page ceiling The live site has >100k events for one event name, so the paged path logs that its counts are a lower bound. The previous code had the identical 100k ceiling - the 46.3 MiB body was that ceiling being hit - but truncated in silence. The ceiling is unchanged; it is now visible. --- PHASE2-FINDINGS.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/PHASE2-FINDINGS.md b/PHASE2-FINDINGS.md index 65b46020b..73b26a2c7 100644 --- a/PHASE2-FINDINGS.md +++ b/PHASE2-FINDINGS.md @@ -588,6 +588,27 @@ A prediction worth recording, because it confirms the mechanism rather than just outcome: at `pageSize=1000` the largest allocation measured 0.7 MiB, and at 5,000 it measured 2.4 MiB — 5× the page size, 3.4× the bytes, exactly as a per-page bound implies. +### What the real instance revealed + +Widget readiness is identical before and after — 28/28 on the board carrying the three +Umami widgets, and the same single pre-existing error on the other board — so nothing broke. +But the container log from the "after" runs contains something the "before" runs could not +have produced: + +``` +warn: Event time series hit the page ceiling, counts are a lower bound + module="umami-integration" eventName="Add app" maxRecords="100000" +``` + +That site really does have more than 100,000 events for one event name in the window. **The +old code had exactly the same ceiling** — `pageSize=100000` is 100k records — and the 46.3 MiB +body it received was that ceiling being hit. The difference is that it truncated in silence +and reported the undercount as fact. The ceiling is unchanged; it is now visible. + +This is also the worst case for the round-trip trade-off: that one event name costs 20 +sequential requests. It did not show up in board load latency (523 ms vs 526 ms median), +because the widget fetches after the board renders, and total CPU rose 4%. + ## Why 24 MiB of code is resident before the first request The module cache is a flat list with no parentage, so "what pulled this in" needed the