Bars cache and history pipeline: cache, coverage, broker, live
Every footprint chart loads its bars through one controller: read the local SQLite cache, ask the cache which windows are missing, fetch only those from the broker, then apply live batches. The cache is keyed on a canonical instrument and stores the 1-minute grain from which intraday timeframes are derived.
Senzoukria · Documentation · Updated September 2026
Where to find it
- Phases
- idle → cache → ensure → live, reported with a progress percentage that never goes backwards during one run
- Pivot grain
- 1m. Every intraday timeframe that divides evenly is summed locally from cached 1-minute bars; 1d and count bars (100t, tick/volume/range/delta) are cached at their own grain
- History range
- Chart settings → "History range": 24 hours (today), 3 days, 7 days. Default 24 hours (today). The window asked of the broker is range × 24 hours back from now, independent of the display timezone; the daily timeframe keeps a floor of 360 hours
- Where the cache is managed
- Settings → "Cache and brokers" points to the Account page: "Data feeds, brokers and the local cache live on the Account page." No control in the chart deletes cached bars
What it does
The history controller runs the same sequence for every data source. First it pages the cache (cache_query_page, 1,000 rows per page, at most 64 pages) for the requested window. Then it asks cache_coverage for the gaps inside that window and hands only those gaps to the broker (rithmic_history_ensure with the instrument tick size). Finally it subscribes to live batches and merges them into the same store.
Bars are stored per bucket timestamp with a provenance: synthetic, ohlcv, cache, hist or live. A merge rule decides which copy wins: a real bar always replaces a synthetic one, a live bar replaces the forming bucket, OHLCV never overwrites an existing bar, and otherwise the copy with more volume (then more trades) is kept. This is what lets a cached bar, a re-fetched bar and a live bar coexist without doubling volume.
Non-Rithmic symbols are normalised to a canonical key such as ESZ6.CME (root, month code, last digit of the year, exchange) so that "ES 12-26" from a bridge and "ESZ6" from Rithmic share the same cache rows. Rithmic symbols are stored as sent, with the exchange appended when known.
Settings and limits
| Setting | Default | What it changes |
|---|---|---|
| History range (chart settings) | 24 hours (today) | Window requested from cache and broker: 1, 3 or 7 days × 24 hours back from now. The display timezone governs the axis, not the amount of data. Offline, the cache window is anchored on the newest cached bar instead of the clock |
| Bar cap per timeframe | 15s/30s 200 · 1m 1,500 · 3m 1,200 · 5m 2,100 · 15m 3,000 · 1h 4,500 · 1d 400 · 100t 1,500 | Maximum bars kept in memory; caps of minute timeframes (except 1d) are multiplied by the range in days |
| Custom timeframes | 120 to 1,500 bars (25 hours), 2h and above up to 4,500 (190 days) | Cap computed from the period when the timeframe is not in the table |
| Tick size | From the instrument catalogue | Passed to the ensure step; without it the backend buckets on the default grid and the window is never marked covered |
| Reload history | Button | ⚙ → Trading Settings → Reload history re-opens windows the broker drained to zero ticks; it clears nothing |
How to use it
- Open the chart at the timeframe you need; history fills itself and stays on disk, so the next open reads the cache before asking the broker.
- Switch between 1m, 5m, 15m and other derivable timeframes freely: they are summed locally from the 1-minute grain, no round-trip.
- Widen History range only when needed: a week of 1-minute footprint is many ticks and the first load takes a while.
- When a notice says another history load is running or loading stalled, press Reload history in the chart settings — nothing else in the app re-opens a window that came back empty.
Notices and pitfalls
- "CME Globex is closed" means there is nothing new to download; cached bars remain on the chart and a drained session can still be replayed.
- rp_code 13 refusals are usually intermittent; the chart keeps running on cached and live data and retries on its own.
- "This instrument's price grid is unknown" means the tick size is not in the catalogue, so history is re-downloaded on every load until it is added.
- A window that came back empty is never asked again automatically; Reload history is the only thing that lifts that.
- The ensure phase has a 120-second stall watchdog and retries a busy backend after 3 seconds; the controller never calls cache_clear or touches localStorage.
- The History range hint in Settings says the window is counted from midnight in the chosen timezone; the history controller asks for range × 24 hours back from now instead, so a chart read late in the day can carry a little more than a calendar day.
Related pages
- Crypto history download
- Filling long history for backtests
- Glossary: tick size
- How to read a footprint chart
This page in other languages
Frequently asked questions
- Why does the chart show bars while the progress bar is still moving?
- The cache phase publishes bars as soon as pages are read (up to 25 % of the progress), then the ensure phase fills the gaps the broker still has to send.
- Can I wipe the cache to fix a bad load?
- The history controller never calls cache_clear and the chart offers no wipe. The lever is Reload history in the chart settings, which re-opens only the windows that returned zero ticks and leaves the cached bars and the live feed alone.
- Are bridge and Rithmic caches shared?
- Rows are keyed on the canonical instrument key, so an ES December contract seen from a bridge and from Rithmic maps to the same key when the symbol can be parsed.