Closes the one follow-up bar_cache.py promises but nobody filed. Its module docstring (:42-55) says:
Making it general means partitioning on (symbol, source_timeframe, feed, day) so any sub- or super-range composes from the same entries — a different read/write/settlement contract, tracked as a follow-up rather than smuggled in here.
No such follow-up existed. Filing it with the measurement attached, so the open-ended "we should generalize this" becomes a closed decision rather than standing design debt.
The concern, as written
The same docstring, and §12 of the design, warn that the key folds start/end in verbatim, so an entry serves exactly one window:
It does NOT speed up an arbitrary window a user types, which is most of the "loading_bars is ~86% of the dark window" problem this track exists for.
That is the pessimistic reading, and it was never checked against traffic.
What traffic actually does
agent_runs on ATL-runs-main, mode='backtest', last 30 days (full numbers on #514):
126 runs over 13 distinct (start, end) windows
runs landing on an ALREADY-SEEN exact window: 113/126 = 89.7%
2026-05-04 -> 2026-05-12 x63
2026-04-01 -> 2026-04-30 x13
2026-04-15 -> 2026-04-16 x6
2026-06-01 -> 2026-06-30 x6
2026-07-01 -> 2026-07-31 x6
Replaying the same traffic against a simulated day-partitioned key:
fully covered by earlier runs: 115 (91.3%)
partially covered: 4 (3.2%)
no overlap at all: 7 (5.6%)
The decision
89.7% → 91.3%. +1.6 percentage points, for a different read/write/settlement contract across the whole module.
Users do not type arbitrary windows — they re-run the onboarding default and a handful of calendar months. The verbatim key already captures nearly all the reuse a general key could, so the altitude limit is real in principle and near-empty in practice.
Recommendation: do not build it. Closing this as the record of that, rather than leaving the docstring pointing at a follow-up that says "someone should generalize this".
What would change the answer
The measurement is a snapshot of a small user base whose traffic is dominated by one default window (63 of 126 runs). Worth re-running the same query if:
- the onboarding default stops being the overwhelming majority of runs, or
- a date-range picker ships that makes arbitrary windows the norm, or
- the distinct-window count grows past roughly the entry cap, where partitioning starts to buy eviction behaviour as well as hit rate.
Until one of those happens, the 1.6 points are not worth a contract change.
Refs #506, #514.
Closes the one follow-up
bar_cache.pypromises but nobody filed. Its module docstring (:42-55) says:No such follow-up existed. Filing it with the measurement attached, so the open-ended "we should generalize this" becomes a closed decision rather than standing design debt.
The concern, as written
The same docstring, and §12 of the design, warn that the key folds
start/endin verbatim, so an entry serves exactly one window:That is the pessimistic reading, and it was never checked against traffic.
What traffic actually does
agent_runsonATL-runs-main,mode='backtest', last 30 days (full numbers on #514):Replaying the same traffic against a simulated day-partitioned key:
The decision
89.7% → 91.3%. +1.6 percentage points, for a different read/write/settlement contract across the whole module.
Users do not type arbitrary windows — they re-run the onboarding default and a handful of calendar months. The verbatim key already captures nearly all the reuse a general key could, so the altitude limit is real in principle and near-empty in practice.
Recommendation: do not build it. Closing this as the record of that, rather than leaving the docstring pointing at a follow-up that says "someone should generalize this".
What would change the answer
The measurement is a snapshot of a small user base whose traffic is dominated by one default window (63 of 126 runs). Worth re-running the same query if:
Until one of those happens, the 1.6 points are not worth a contract change.
Refs #506, #514.