Every performance figure quoted in the quota lens' comments — 14.93 days and 109,278 messages at 67 seconds, 5.4 days and 45,844 at 4.6 — is a snapshot of a young store. Nothing in the code keeps them true as history accumulates.
The scan range follows the oldest cycle, not the displayed one. rebuildQuotaHistory joins over all of quotaCycles, and refreshWindowUsage takes from = min(windowStart, quotaCycles.last?.startMs ?? windowStart) — quotaCycles is newest-first, so .last is the oldest recorded cycle. The engine retains 128 cycles per series; QuotaHistoryCard displays 12. A 5-hour session window at 128 cycles is a 26-day scan.
qualifyingCycles has no ceiling at all. stripLength = 16 bounds what the strip draws, not what the equivalence admits, and equivalenceStart is the minimum start across every qualifying window's oldest cycle. A weekly window adds one cycle a week, so that start walks backwards indefinitely.
The pooled equivalence re-walks the scan per cycle. rebuildQuotaEquivalences filters scan.messages once per cycle on the main actor — the same shape QuotaHistoryFold.rows documents having removed ("15 × 45,844 walks on the main actor"), reintroduced by a second implementation of the same fold. The two should share one spanTotals rather than each computing it.
Not urgent: it is paid only on the Quota lens with an agent tab open, the scan is async behind a 30s cache, and the degradation is gradual over weeks. But it degrades silently, and the numbers in the comments will keep reading as current long after they stop being.
Shape of the fix: cap the join and the admitted-cycle set to a shared constant (16 most recent admitted cycles is enough for the jackknife, and a shorter pooling window is more honest given the estimator provably cannot see a plan change across a long one), which bounds the scan start as a consequence. Then have the two span folds share one implementation.
--window-probe is the instrument for re-measuring; it was kept for this.
Raised by a structural review of #227.
Every performance figure quoted in the quota lens' comments — 14.93 days and 109,278 messages at 67 seconds, 5.4 days and 45,844 at 4.6 — is a snapshot of a young store. Nothing in the code keeps them true as history accumulates.
The scan range follows the oldest cycle, not the displayed one.
rebuildQuotaHistoryjoins over all ofquotaCycles, andrefreshWindowUsagetakesfrom = min(windowStart, quotaCycles.last?.startMs ?? windowStart)—quotaCyclesis newest-first, so.lastis the oldest recorded cycle. The engine retains 128 cycles per series;QuotaHistoryCarddisplays 12. A 5-hour session window at 128 cycles is a 26-day scan.qualifyingCycleshas no ceiling at all.stripLength = 16bounds what the strip draws, not what the equivalence admits, andequivalenceStartis the minimum start across every qualifying window's oldest cycle. A weekly window adds one cycle a week, so that start walks backwards indefinitely.The pooled equivalence re-walks the scan per cycle.
rebuildQuotaEquivalencesfiltersscan.messagesonce per cycle on the main actor — the same shapeQuotaHistoryFold.rowsdocuments having removed ("15 × 45,844 walks on the main actor"), reintroduced by a second implementation of the same fold. The two should share onespanTotalsrather than each computing it.Not urgent: it is paid only on the Quota lens with an agent tab open, the scan is async behind a 30s cache, and the degradation is gradual over weeks. But it degrades silently, and the numbers in the comments will keep reading as current long after they stop being.
Shape of the fix: cap the join and the admitted-cycle set to a shared constant (16 most recent admitted cycles is enough for the jackknife, and a shorter pooling window is more honest given the estimator provably cannot see a plan change across a long one), which bounds the scan start as a consequence. Then have the two span folds share one implementation.
--window-probeis the instrument for re-measuring; it was kept for this.Raised by a structural review of #227.