Merged as v0.25.1.

• MR: https://gitlab.wikimedia.org/daanvr/upload-workbench/-/merge_requests/43
• Live: https://upload-workbench.toolforge.org/ (and permanent archive at https://upload-workbench.toolforge.org/v0.25.1/)
• Diff: 16 lines changed in src/app.jsx + CHANGELOG + CLAUDE.md durable-rule entry.

Lessons learned

The bug was a textbook React infinite render loop, but the failure mode was unusually severe: because the loop closed entirely inside the microtask queue (Promise.all([]).then(...) resolves immediately on the cached/no-op path), the event loop never yielded to the renderer or to input handling. That made the tab freeze hard enough that DevTools couldn't even attach to inspect the runaway main thread — so the usual "Profiler shows excessive renders" workflow was unavailable. Diagnosis had to come from reading the code, not from observing the running app.

Three things to remember next time:

1. prev.map() always returns a new array reference, even when every callback returns the original element. Per-row return row; bailouts inside .map only stabilise the elements; the array wrapper is always new. React's Object.is then sees a different reference and re-renders. Inside an effect that depends on the array state, that's an infinite loop. Track a changed flag in the map, return prev (same reference) when nothing changed, and let Object.is bail.

2. Microtask-only loops freeze the tab silently and undebuggably. A loop that goes through the macrotask queue (e.g. setTimeout(fn, 0)) eventually yields and lets the browser show "page unresponsive" with stack info; one that goes through the microtask queue (any synchronous-resolving promise chain) starves the event loop entirely. DevTools require the main thread to service their CDP messages — a microtask-only loop blocks attach. So: if a user reports "freezes and DevTools won't open", look for Promise.all, Promise.resolve, or await-on-already-cached-value patterns inside effects.

3. The [items] dependency on a memoised array is fragile when paired with state setters that always produce new array references. Whenever you write setState((prev) => prev.map(...)) inside a useEffect whose dep is the same state, ask: "what stops this from looping?" If the answer is "the per-row bailout returns the original row" — that's not enough. The answer needs to be "the setter returns prev (same reference) when nothing changed."

Rule added to CLAUDE.md → "Durable rules learned so far" so this doesn't recur silently.

Total time from user-reports-freeze to merged fix: ~45 minutes (most of it in worktree/CI ceremony — the diagnosis itself was ~10 min once the loop hypothesis was confirmed by reading the cat-check effect).