prom_proxy: every tile reads over the selected range

[aaylward]

The castle tiles said 0.00 under a 1d trend chart that plainly showed the games: the tiles read a fixed five minutes while the chart read the selected range.

Now /service/{name} takes ?range= (30m, 1d, 7d; a day when absent) and every windowed tile reads over it: the standard Serving numbers, both views of every counter, and the windowed means. The response echoes window so the UI can label what it shows. A tile query Prometheus refuses (a week-long lookback past its sample budget, say) still reads zero, per the outage contract, but is logged now rather than indistinguishable from a real zero.

Gone with it: counterOver, alarmWindow and burstWindow (the day-long windows a few tiles carried to stay lit are what the default range gives every tile), the _5m/_1h label suffixes on the windowed means, and success_count_5m/failure_count_5m, which are success_count/failure_count — the site never read them. A fixed-form tile writes its window as [w], filled per request; charts keep windowing by their own step, and defaultCounterWindow is chartRateWindow, which is what its comment already said it was.

Tests: every tile's queries at a 7d range carry [7d] and nothing else in brackets, and the audits' view of them carries the default range; every chart query at two steps carries only real durations, so a chart shipped with the tiles' slot unfilled fails; no label names a window; each range's window is its own name and the default is a day; the handler windows every tile by ?range=, echoes it, defaults it, and 400s a bad one. Review panel ran 20 mutations; the one survivor (a chart built with the slot) is the chart test above.

Site half is muchq/muchq.github.io#317: it sends the range, captions the requests tile from the echoed window, says the span once on the range select, and refetches a week every five minutes rather than every thirty seconds, since at 7d each tile is a week-long instant query. Until it lands, a new proxy answers an old site's rangeless request over a day, under the old "Req (5m)" caption. At 7d a p95 or error % is a week's figure, which is the ask.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NvyU4MCzgsmRNa33yW1YNM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	1d4-web	750cf07	Commit Preview URL Branch Preview URL	Sep 07 2026, 07:03 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	iili	750cf07	Commit Preview URL Branch Preview URL	Sep 07 2026, 07:03 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	ast-lol	750cf07	Commit Preview URL Branch Preview URL	Sep 07 2026, 07:04 PM

[aaylward]

Verdict

Approve — 0 blocking, 1 non-blocking

(Posted as a comment: GitHub won’t let the author submit an approve review.)

This is the right fix for the castle tile / chart mismatch: one range drives every windowed tile, charts keep their own step windows, and the response echoes window the same way it already echoes view. CI is green; the site half (#317) is paired and documents the dual-deploy story. Safe to merge as-is; one cheap test pin would make the new JSON key as hard to rename accidentally as view already is.

What Was Done Well

• Collapsing counterOver / alarmWindow / burstWindow into the request range removes a whole class of “tile on its own clock” bugs (#1323) without special-casing sparse counters.
• [w] + QueryFor(view, window) is a clean template fill; charts staying on chartRateWindow / step is correctly separated and locked by TestRegistry_ChartsCarryNoWindowSlot.
• Registry audits were rewritten around the new contract (EveryWindowedTileReadsOverTheRange, LabelsNameNoWindow) rather than left asserting the old 24h constants.
• Logging Prom refusals while keeping the zeroed outage contract makes a sample-budget failure distinguishable from a real zero — important once 7d instant queries are in play.
• Default 1d keeps overnight alarms lit for the page people land on; the PR is honest about old site + new proxy caption skew until #317 ships.

Non-Blocking Issues

• service_handlers_test.go (JsonKeysAreStable): assert raw["window"] == "1d" on a rangeless request next to raw["view"]. That test exists so a json tag rename doesn’t stay green while the other-repo UI loses the field; Window is documented as View’s twin, and the site captions from it.

Test Coverage

Solid for the new contract (handler ?range=, invalid range 400, default echo, registry window/slot/label audits). No coverage gap I’d block on.