Timeline panel: an unanswered request in an Earlier window shows the wait up to the window end, not to now #1797

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 991e7a8655534c839c89c8057d72b91a
Branch: dev/1-earlier-wait-now
Base: 6a6f22b
At: 2026-10-30T05:24:19Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What a person sees

In the Timeline panel, press Earlier to look at a stretch of history. An unanswered request in that window is labelled waiting 2.0 s even though it has been waiting 4.0 s (in real use: minutes or hours) — the label stops at the window's end. The same screen already says 1 request not answered yet, and alerts and the digest count that same request up to now, so two numbers for one request disagree and the smaller one is on screen.

Where (main 92a4cf262cb8f2469f800f12e5cfe006abb4d538)

• plugins/timeline/client.js:322 — label: waiting ${fmtDur(to - e.t)}, ms: to - e.t, where to is the end of the reviewed window (win.to).
• The host side already gets this right: plugins/timeline/src/window.js returns both now and to, and its stuck list uses waitedMs: Math.max(0, now - arrow.t). Only the swimlane label uses the window end.

Reproduction

Open Timeline, pick a 1-minute window, press Earlier to step back half a window, and read an unanswered request's label: waiting 2.0 s while the bottom line says it is still unanswered and alerts for the same window count the full wait.

Red first, on the current tree, using the existing plugins/timeline/test/panel.test.js fixture (x3 sent at at(41000) with no reply anywhere in the trace, NOW = at(45000)), with win({ to: at(43_000), windowMs: 60_000 }) standing in for the Earlier window, asserting g.arrows.find(a => a.id === 'x3').wait.label === 'waiting 4.0 s':

not ok 21 - QA probe: an unanswered request in an Earlier window shows the true wait, not the window end
  + 'waiting 2.0 s' - 'waiting 4.0 s'

Expected

An open wait always counts to now, whenever the review window ends; the drawn line still stops at the window's right edge. The bottom not answered yet line, alerts and the digest all agree with the label.

Scope

layoutSwimlanes only: compute the open wait from (win.now ?? to) - e.t for label/ms, leave x1 at the window edge (~3-5 lines), one case in plugins/timeline/test/panel.test.js, one changelog.d/ fragment. No window.js change, no patches/, no generate.

Dedupe (searched 2026-10-30, open + closed)

• timeline waiting earlier window → 18 hits; timeline "waiting" unanswered → 8 hits. Nearest are feat(timeline): panel with swimlanes, who-waits-on-whom map and utilization #247 (the panel itself), Turn the timeline window into a run report a person can paste #735 (window to report), Timeline: durable alerts (open once, resolve when cleared) #584/Add durable timeline alerts (#584) #731 (durable alerts) — none about an Earlier window computing the wait from the window end.