Files
pad/web/src
xarmian af24997c72 fix(web): re-resolve the follow target by id at fire time (BUG-2848)
Codex round 1, P2, and a real latent bug in the previous commit. Capturing the
item OBJECT and reusing it 140ms later keeps a stale snapshot: a rename during
the debounce changes the slug, `openItemPane` builds the URL from that slug, and
the id-only existence check passes happily on the way to a dead URL.

What is captured is now the IDENTITY — `targetId` — and the callback re-resolves
the current row from `filteredItems` before opening it. That still follows a row
that MOVED, which is the whole point of the fix, and still skips one that was
DELETED, while picking up any change to the row itself.

Also answering the round's second P2 in the spec rather than in code: the race
is probabilistic and cannot be made deterministic without a seam in the page.
The asymmetry is what makes that acceptable, and it is now written down — a
round that misses the 140ms window still PASSES on a correct build, because the
cursor moves, the pane follows and the intended row is where it should be. So
missing costs power, not correctness; the failure mode is a false green, never a
false red. Three rounds put a false green around 1 in 1700 against a build that
loses the keypress 11 times in 12.

pane-follow-live-list + pane-controller: 44/44 across both projects.
2026-09-02 22:07:46 +00:00
..