**Note** from Bead: Time Line Web Component · [canonical source](https://redfish.acequia.io/guerin/.agents/ade9cea6-f50e-4922-8266-4bdd14ed9c73/2026-06-19/notes/01-process-latest-on-complete-audit.md) · session 2026-06-19 · discussion: Talk: Time Line Web Component
**Question (Stephen, 2026-06-19):** reference the `.ai/` guidance about "processing last event when scrubbing" and check whether https://redfish.acequia.io/guerin/apps/camera-grid/ follows it. **The guidance:** `.ai/process-latest-on-complete-UI-pattern.md`. A single-slot `pending` buffer holds only the most recent scrub event; a `busy` flag prevents double-processing; the **completion callback of the previous render** drives the next one. Intermediate events are discarded by *overwriting* `pending`. The loop is completion-triggered, not timer-triggered. It is preferred over debounce (adds latency, ignores render cost) and throttle (can still queue if render > interval).
## Verdict: **No — camera-grid does not follow the pattern.** The scrub path in [`index.js`](file:///c:/Users/steph/Documents/sites/redfish.acequia.io/guerin/apps/camera-grid/index.js): ```js function seekFromX(clientX) { const r = canvas.getBoundingClientRect(); playhead = Math.max(tMin, Math.min(tMax, xToT(clientX - r.left))); updateWall(); // <- runs synchronously on EVERY pointermove } let scrubbing = false; canvas.addEventListener('pointerdown', (e) => { scrubbing = true; ...; seekFromX(e.clientX); }); canvas.addEventListener('pointermove', (e) => { if (scrubbing) seekFromX(e.clientX); }); canvas.addEventListener('pointerup', () => { scrubbing = false; }); ``` Every `pointermove` calls `updateWall()` immediately. `updateWall()` loops all cameras, runs a binary search per camera (`nearestFrame`), sets `img.src` for changed tiles, then redraws the canvas (`drawTimeline`) and `syncMapAz()`. There is **no** `pending`/`busy`/completion-callback loop, **no** `requestAnimationFrame` coalescing, and **no** timer. It is the naive "process every event" path the guidance warns against.
## Why it has not visibly bitten yet (the two accidental mitigations) 1. **Per-tile change guard** — `if (t.img.dataset.url !== fr.url)` skips re-assigning `img.src` when the nearest frame did not change. This is *conflation by value*, not by completion: during a slow drag across dense frames it still re-sources up to ~10 images per event. 2. **Browser cancels superseded image loads** — reassigning `img.src` on the *same* element aborts the prior in-flight request, giving switchMap-like drop-of-stale **per tile**. So the network mostly self-corrects, but the **synchronous CPU cost** (10 binary searches + a full canvas redraw + per-tile DOM writes) still runs on every pointermove, and image *decode* of intermediate frames can still land out of order. So it survives because the wall is only ~10 small remote thumbnails and the browser does some of the work the pattern would do explicitly. It is not robust: more cameras, larger frames, or a heavier per-tile render (3D map view, az wedges) will reintroduce exactly the backlog the pattern prevents.
## The fix (and why it belongs in the shared component, not this app) Minimal faithful adaptation — coalesce to the render loop with a single-slot scheduler: ```js let pendingX = null, busy = false; function onScrub(clientX) { pendingX = clientX; if (!busy) pump(); } function pump() { if (pendingX == null) { busy = false; return; } busy = true; const x = pendingX; pendingX = null; const r = canvas.getBoundingClientRect(); playhead = Math.max(tMin, Math.min(tMax, xToT(x - r.left))); // heavy work, then drive the loop on completion: requestAnimationFrame(() => { updateWall(); pump(); }); } ``` For full fidelity the completion trigger should be the **render actually finishing** — e.g. await the nearest/primary tile's `img.decode()` (or `Promise.allSettled` of the visible tiles' decodes) before calling `pump()`, so slow renders naturally skip more intermediate playhead positions. rAF-coalescing is the floor; decode-gated is the ceiling. **Architectural takeaway for this bead:** process-latest-on-complete is exactly the kind of behavior the **shared timeline web component** should own once, so no app re-derives it (and camera-grid re-derives it *incorrectly* by omission). It becomes design question #7 in `notes/00`. The component's scrub event should be internally conflated and completion-gated; apps just supply the heavy `render(t)` and (optionally) a "render done" promise.
## Offer — SENT 2026-06-21 This finding + the minimal-fix snippet was POSTed as a **request** to the firewatch-camera-grid bead's `request/` dock (per Stephen): `65783732…/request/2026-06-21T005026-timeline-bead-process-latest-on-complete.md` (+ `.meta.json`, `kind: "request"`, respond-to `response/`). Asking it to adopt process-latest-on-complete on the wall scrubber and CDP-verify. This bead does not edit the app in place; the ball is in firewatch's court.