ottyl/tickets/057-rate-line-chart-x-axis-collapses-to-sparse-occurrence-window.md

# 057 — Line chart for a rate() over sparse/bursty occurrences collapses its x-axis to the data's own tiny time span

## Summary

Reported symptom: the dashboard line chart for `sum by (code) (rate(KeyPressed[5m]))`
looks bad/unreadable against a real capture
(`ottyl --file .../sim-world.log`, a ~10-hour log where `KeyPressed` is a
user-declared metric matching `msg="key_event"` lines, labeled by
`code`/`kind`/`msg` — see the profile's metric declaration in
`~/Library/Application Support/ottyl/settings.json`). In the sample log
all 20 `key_event` lines (16 `Left`, 3 `Up`, 1 `Down`, all `kind="Press"`)
occur within the first ~10 seconds of ingestion; there are zero further
key presses across the remaining ~9h55m of the log.

Two compounding causes, both reproducible from this shape of data:

1. **`rate()` never emits a trailing zero once occurrences stop.**
   `crate::rate::windowed_rate_series` (`src/rate.rs:40-45`) evaluates
   `rate_at` only *at each existing point's own timestamp* — there is no
   synthetic point emitted at the query's `end_ms` (or at "now") once the
   trailing window has aged out. `evaluate_promql`'s `Sum`/`Avg` branch
   (`src/engine.rs:1621-1648`) calls this per group then merges with
   `merge_series_locf` (`src/engine.rs:1508-1529`), which sweeps only the
   *union of each sub-series' own timestamps* — again nothing beyond the
   last real occurrence. So a series for `code="Left"` literally ends at
   the timestamp of the last `Left` press; there is no data point saying
   "rate is now 0" for the following ~9h55m.
2. **The frontend's line chart x-axis auto-scales to whatever timestamps
   happen to be in the returned series, not to the queried time range.**
   `PanelChart.tsx`'s `toLineData` (`webapp/src/components/PanelChart.tsx:60-77`)
   builds `rows` only from timestamps present in `series[].points`; the
   `<XAxis dataKey="timestamp_ms" .../>` (`PanelChart.tsx:105-110`) has no
   explicit `domain`, so Recharts defaults to `['auto','auto']` computed
   from `rows` alone. Combined with (1), a panel queried over "last 6
   hours" (or any range spanning the whole log) that only has data in the
   first 10 seconds silently renders an x-axis spanning just those 10
   seconds — not the selected range — with no visual indication the axis
   has been narrowed or that activity stopped. The result is a cramped,
   jagged little chart (peak rate ≈ 16 presses / 300s ≈ 0.053/s, so also
   visually flat/near-zero) that looks broken rather than showing "a
   burst, then nothing."

The backend range filter (`start_ms`/`end_ms` in `evaluate_promql`,
`src/engine.rs:1565-1584`) is applied correctly to which raw occurrences
are considered — this is not a filtering bug, it's a rendering/shape
problem in what gets returned and how it's charted.

## Scope

- Decide and implement a way for the charted line to reflect that the
  rate has decayed to (and stayed at) zero, rather than simply stopping.
  Options to weigh (pick one, document the choice in the PR):
  - Emit a synthetic trailing point at `end_ms` (or "now" for a live
    range) per group whenever the last real point's window has fully
    aged out and its rate would read 0 — cheapest fix, keeps all
    resampling logic where it already lives in `evaluate_promql`.
  - Resample `rate()`/`sum(rate())`/`avg(rate())` series onto a regular
    step grid across `[start_ms, end_ms]` (à la Prometheus's `step`)
    instead of only at occurrence timestamps — bigger change, but fixes
    the same problem for gauges/counters with irregular sampling more
    generally; note `merge_series_windowed` (`src/engine.rs:1484-1503`)
    already buckets on a fixed `MERGE_WINDOW_MS` grid for the
    non-rate `sum()`/`avg()` path, which is closer to this shape already.
- Whichever approach is chosen, make `PanelChart.tsx`'s line chart honor
  the panel's actual queried range for the x-axis domain (pass
  `range.startMs`/`range.endMs` down from `Dashboards.tsx`'s
  `PanelPreview` into `PanelChart` and set `<XAxis domain={[startMs,
  endMs]} type="number" .../>`, or equivalent) so a chart with sparse
  data doesn't silently narrow the visible window — this is worth doing
  regardless of which backend option above is chosen, since it's the
  more directly misleading half of the bug.
- Add a fixture reproducing this shape (a metric with occurrences
  clustered in a short burst near the start of a much longer ingested
  window) and a test on `evaluate_promql`/`windowed_rate_series` (or
  wherever the chosen fix lives) asserting the returned series covers
  the full requested range, not just the burst.
- Out of scope: changing how `KeyPressed`-style occurrence metrics are
  declared, or adding a dedicated "gauge decay" concept — this is about
  the query range/x-axis mismatch specifically.

## Acceptance criteria

- Querying `sum by (code) (rate(KeyPressed[5m]))` (or an equivalent
  fixture) over a time range much wider than the span of actual
  occurrences returns a series (or is charted) that visibly reflects
  rate-zero for the remainder of the range, rather than a line that
  simply stops.
- `PanelChart`'s line chart x-axis reflects the panel's selected/queried
  time range, not just the min/max timestamp actually present in the
  returned series — verified by a case where returned data covers only
  a fraction of the selected range.
- Existing `evaluate_promql`/`rate.rs`/`PanelChart` tests for
  regularly-sampled or continuously-occurring metrics are unaffected.

## Depends on

None.