v1.3.42.3: the long-range readers move to the hourly rollup (unreleased)¶

Planning: docs/planning/v1.3.42.3-rollup-readers-phase0.md (operator's conditions of 2026-09-28: histogram percentiles say so on the card and api.md lists the edges; deploy only after drift verdicts 7 and 8 at 0). No schema, no long write, no bouncer change.

What ships¶

• One reader in internal/db/rollup_read.go: RollupSpanFor splits a window into the head edge, the closed hours the rollup holds and the live tail; ReadRollupHours / ReadRollupPaths read the closed span through the rollup indexes; Hist merges the 8-bucket duration histogram of rollup rows and live rows and resolves nearest-rank percentiles to the bucket edge (the merged maximum above 5,000 ms).
• Dashboard traffic: 1h and 6h unchanged on rows (percentile_method: exact); 24h, 7d and the new 30d stitched (histogram): the 24 h status series stays at 15 min from an index-only scan of the status index, response times one point per hour (6 h on 30d), top hosts, top paths and bandwidth over the whole range. Overview counters the same way. The pinned 24 h refresh no longer visits the rows that carry raw.
• logs/stats and logs/timeseries (hourly buckets) on time-only filters with at least one closed hour in the window: stitched; the covering-index path of v1.3.38.4 stays only as the fallback while the rollup has no hours (percentile_method: sample).
• X-Argos-Path: rollup | rows on overview, traffic, stats and timeseries; percentile_method in the traffic and stats bodies. Gone: detail_window, detail_from, series_covers_range, sample_n, the "(last N h of range)" card titles.

• Endpoints take the URL vocabulary: range on /api/logs, /api/logs/stats, /api/logs/timeseries, /api/logs/export.csv, /api/notifications/deliveries (alternative to from/to) and /api/appsec/metrics (alias of window); q on /api/threats/decisions. lib/filters.ts lost rangeFrom, rangeToDash and rangeToAppSecWindow; the pages send range as is. Dashboard presets 1h / 6h / 24h / 7d / 30d (the security section clamps 30d to 7d, it stays on rows); Logs presets gain 30d; the p95 cards say "histogram (bucket edges)" with the edges in the tooltip.

• Monthly VACUUM on the calendar (1^st of the month, 04:00 UTC) with a catch-up at boot when the recorded run is older than the last slot; the first boot with this code only records the last slot, so on prod the first run is 2026-10-01 04:00 UTC (the sampler scripts/ops/vacuum-sample.sh is for that run). The old check ran on a 24 h ticker from boot and never fired unless the panel had started inside hour 04 UTC.

• read-pool.sh: STRIP_WAIT_S (120 s) and an explicit PASS "nothing to strip" instead of waiting CAP_S for a purge line the panel only writes when it had work.

Verified on the dense demo (rc3 image, 2026-09-28)¶

Demo stack with scripts/demo/seed-dense.sh (500,000 rows over the 7 days ending at the seed time, 480k access rows of 1.5 KB raw), the rollup reset by hand and re-filled by the boot backfill (168 h in 40 s), rc3 = commit 1415af4 of the branch plus the docs commits.

Found and fixed during the run: with an empty rollup (the minutes before the first fill, or a reset) 30d fell back to the row path and hit the loader deadline on the dense seed; long ranges without a rollup hour now answer the series and top hosts from the indexes with a note (commit 2c134cd). The demo also showed that read-pool.sh waits forever for retention purge done when the strip has nothing to do (the panel logs the line only when it removed or stripped rows); with raw_hours 720 on the demo the default STRIP_HOURS=6 strips nothing, hence STRIP_HOURS=600.

Deploy¶

Drift verdicts 7 and 8 landed at 0 (2026-09-28 11:56 and 19:58 UTC, hours 08:00 and 16:00, 2,239 and 1,685 rows, both sides equal on the volume); the gate is met. With the operator's OK: make deploy-prod from main once this branch is merged; rollback = repin 1.3.42.2. After-smokes: rollup-readers.sh, rollup-agree.sh, read-pool.sh gates 0-3, dashboard-latency.sh, panel-boot.sh, the next two drift verdicts.

Results (deployed 2026-09-29 19:26 UTC)¶

Verdicts 9 to 11 also landed at 0 before the deploy (01:58, 07:58, 13:58 UTC on the 29^th). make deploy-prod from main (fb58d0a) at 19:25:43 UTC: sync of 62 files, image build, recreate at 19:26:59, healthy 10 s later, /healthz 200, no rollback. Boot log: read pool enabled, boot purge at 19:29:07 UTC (14,751 removed, 9,759 stripped), boot backfill of the one hour the restart cut (18:00 UTC, 24 ms), vacuum schedule initialised with last slot 2026-09-01 and next 2026-10-01 04:00 UTC (the first boot records, it does not run).

Found on the prod 7d capture (not on the dense demo): the p99 line of the response-time card reads up to 457,244,622 ms. Hist.Percentile returns the hour's maximum duration when the rank falls in the open bucket above 5,000 ms, and on prod that maximum is the lifetime of a long-lived connection: /api/websocket rows of 5.3 days, /socket.io/ of 80 min, camera-proxy streams of 35 s. Ten of the 169 hours in the window have more than 1 % of their requests above 5 s (all on 09-25 and 09-26), so ten p99 points are between 373,940 and 457,244,622 ms and the chart's axis scales to 60,000,000. The rollup's exact dur_p99_ms column does not help: the websocket-only group carries the same maximum. The 24h card shows the documented quantisation (50 / 100 / 250 / 500 / 1,000 / 2,500 / 5,000) as flat steps where the rows path drew a line. Reported to the operator before the tag.

Known issues carried¶

From v1.3.42.2: AppSec fail-open under a scanner burst at 1 CPU (stream pre-flight data point), Until on imported decisions, blocked_requests_24h mixing, dashboard/cache_test timing flake. The VACUUM schedule bound to the boot hour is fixed here. New: traffic 24h with a host filter still reads that host's rows (2.6 s cold for the busiest host on the dense demo; on demand, not pinned); hourly from the rollup in 43.x. On the rollup path top_hosts counts rows with a host link and top_paths counts access rows (api.md).