fix(webui): guard submitEdit against re-entry (destructive double-submit)

[alanjds]

The report

On a laggy instance, one user clicked "Send edit" repeatedly because the UI had not acknowledged the first click. Their network log:

POST /api/session/truncate   5189ms  8336ms  6658ms  7449ms  8053ms  8541ms   ×7
GET  /api/session?messages=1 6400ms

Seven concurrent truncates from one intended edit.

Why

submitEdit's only re-entry guard was S.busy — but send() does not set that until the last line, after two multi-second awaits:

if(!S.session || S.busy) return;              // S.busy still false
const absoluteKeepCount = _oldestIdx + msgIdx;
await _ensureAllMessagesLoaded();             // ~6.4s on a long session
await api('/api/session/truncate', ...);      // 5-8s under load
await send();                                 // S.busy finally set

On a 2000-message session that is a 10s+ window in which every further click runs the whole destructive path again.

The hazard is worse than the load

absoluteKeepCount is captured before the awaits deliberately — at click time _oldestIdx is the loaded window's offset and msgIdx is window-relative, so their sum is the true absolute index. That ordering is pinned by test_submit_edit_captures_absolute_before_await (the nesquena#2184 pattern).

But the first call's _ensureAllMessagesLoaded() sets _oldestIdx = 0. A second call entering after that computes 0 + msgIdx from a msgIdx that is still window-relative — a far smaller keep_count. Truncating a long session to that would delete most of its history.

The reporter's session came through intact, so this is a latent hazard rather than a confirmed loss — but the mechanism is there and truncate deletes messages.

The fix

A module-scope _submitEditInFlight flag, raised before the first await and cleared in a finally.

Guarded at the function rather than the click handler: the edit is also submittable with Enter (the keydown handler clicks the button), so a handler-only guard leaves that path open, and a future caller would silently reopen the hole. The finally means an early return or a throw cannot wedge editing off for the rest of the page's life.

Deliberately not changed

• The pre-await capture stays. Recomputing keep_count after _ensureAllMessagesLoaded() looks like the obvious fix and is wrong — it pairs _oldestIdx=0 with a window-relative msgIdx and breaks Fork from here uses local window index in long sessions nesquena/hermes-webui#2184 outright. (I proposed exactly that before reading the test, and it would have been a regression.)
• regenerateResponse has the same S.busy-only shape, but no longer client-side truncates — it delegates to the atomic startRegeneration and validates the clicked index against latestAssistantIndex, so a double click is refused rather than destructive. Left alone to keep this diff to the fault.
• No UI feedback. Extra clicks are now harmless, but the button still does not visibly acknowledge the first one — which is what provoked the clicking. Worth a follow-up; it is a UX change, not this correctness fix.

Verification, and its limits

Not reproduced end-to-end. This environment cannot run a real agent turn, so the seven-truncate storm comes from the reporter's network log rather than a local repro. The guard is verified by source-level test only.

test_submit_edit_is_guarded_against_reentry pins the flag, that it is raised before the first await, and that it is cleared in a finally after send(). Confirmed to fail when the guard is reverted — the three pre-existing tests in that file pass either way, so they would not have caught this.

Broad sweep: 2457 passed, 13 failed — all pre-existing test_update_banner_fixes.py ordering pollution, identical on a clean tree. One earlier run of the same sweep showed a 14th failure that did not reproduce across two further runs and whose name I did not capture; flagging it rather than claiming a clean baseline.

ruff check clean, node --check static/ui.js clean.

---

Generated by Claude Code