fix: guard new conversation cold-start clicks

[Michaelyklam]

Thinking Path

• The issue reports a cold-start path where POST /api/session/new waits behind model/provider catalog resolution.
• During that wait, the sidebar + button gives no durable pending state, so repeated clicks can enqueue multiple blank sessions.
• A narrow frontend guard can preserve the current backend behavior while making the interaction explicit and idempotent.

What Changed

• Added a single in-flight newSession() promise so repeated New Conversation triggers reuse the same create request until it settles.
• Disabled the sidebar New Conversation button with aria-busy="true" while creation is pending.
• Shows a localized composer status message (Creating new conversation…) during the cold-create window.
• Added source-level regression coverage and a release-note entry.

Why It Matters

This makes the button feel responsive during cold model/provider catalog resolution and prevents accidental duplicate blank sessions from rapid repeated clicks.

Closes #2518

Verification

• env -u HERMES_CONFIG_PATH -u HERMES_WEBUI_HOST /home/michael/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_issue2518_new_session_inflight.py tests/test_1432_newchat_and_1423_profile_input.py tests/test_profile_default_workspace_823.py -q — 20 passed
• env -u HERMES_CONFIG_PATH -u HERMES_WEBUI_HOST /home/michael/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_issue2518_new_session_inflight.py tests/test_chinese_locale.py tests/test_japanese_locale.py tests/test_korean_locale.py tests/test_russian_locale.py tests/test_spanish_locale.py -q — 29 passed
• node --check static/sessions.js
• node --check static/i18n.js
• git diff --check
• Isolated local WebUI screenshot pass on 127.0.0.1:18818

UI Media

Before / idle New Conversation button:

After / pending create state:

Risks / Follow-ups

• This does not speed up cold provider/model catalog resolution itself; it only makes session creation idempotent and visibly pending while that work completes.
• Other callers of newSession() intentionally share the same in-flight promise, so a slash command or shortcut fired during the pending window will land on the same new session rather than creating another duplicate.

Model Used

AI-assisted change with repository inspection, targeted editing, shell-based test verification, and isolated browser screenshot capture.

[nesquena-hermes]

Summary

Reading static/sessions.js:420-520 on this branch against origin/master, and the regression test at tests/test_issue2518_new_session_inflight.py, the fix correctly coalesces concurrent newSession() calls behind a single in-flight promise and adds a couple of nice UX touches the other open #2518 PR doesn't have: a localized Creating new conversation… composer status message (with i18n keys added for the supported locales) and a short toast when the user re-clicks during the pending window.

The shape — module-level _newSessionInFlight, a _setNewSessionPending(true/false) helper that drives both the button state and the composer status, wrapping the existing body in an IIFE so the final try/finally always runs — matches the contract the issue describes.

Code reference

Guard entry/exit at static/sessions.js:435-516 (this branch):

async function newSession(flash, options={}){
  if(_newSessionInFlight){
    if(typeof showToast==='function') showToast(_newSessionPendingText(),1500);
    return _newSessionInFlight;
  }
  _setNewSessionPending(true);
  _newSessionInFlight=(async()=>{
    // ... existing create body
  })();
  try{
    return await _newSessionInFlight;
  }finally{
    _newSessionInFlight=null;
    _setNewSessionPending(false);
  }
}

The composer-status helper at :420-434 is careful to only clear the status if it still matches the pending text — so a setComposerStatus() call from inside the create body (e.g. for a model-default warning) won't get nuked by the cleanup:

function _setNewSessionPending(pending){
  // ...
  const pendingText=_newSessionPendingText();
  if(pending){
    setComposerStatus(pendingText);
  }else if(statusEl&&statusEl.textContent===pendingText){
    setComposerStatus('');
  }
}

That's a good detail — it avoids racing against legitimate status writes from the inner block.

Diagnosis / Recommendation

The change is structurally fine. A few notes:

1. Overlap with PR #2519. That PR is open against the same issue and also lands a module-level promise + disabled / aria-busy / is-loading button state on btnNewChat. The two PRs touch the same function body and will conflict on merge. The maintainer will pick one. The differentiators worth weighing:

• This PR has localized composer-status text and a re-click toast — better user feedback during slow cold starts.
• fix: guard concurrent New Conversation creates #2519 has a Node runtime test that actually executes sessions.js and proves overlapping newSession() calls produce a single fetch — a stronger contract than the static source-string check here.

Neither is strictly superior. Either way, both fixes shouldn't land.

2. The static test at tests/test_issue2518_new_session_inflight.py is structural only. It greps for _newSessionInFlight and the pending-text token in the source. That catches accidental removal but doesn't verify the runtime behavior (single fetch under concurrent calls, button state actually toggles). If the maintainer prefers stronger contracts, this is the gap relative to #2519's runtime harness.

3. The await/finally placement is correct. return await _newSessionInFlight inside a try ensures the rejection from the inner promise propagates and the cleanup runs — equivalent to wrapping the body in try { ... } finally { cleanup() } directly. The IIFE pattern adds an extra microtask, which is fine here.

4. No error toast on rejection. If api('/api/session/new') rejects (network failure, cold provider catalog hits a 5xx), the user sees the busy state clear with no signal beyond the re-enabled button — the composer-status message disappears silently. The pending toast covers re-click during the pending window, but a catch toast inside the IIFE would close the loop for failed creates. Minor; not a blocker.

Verification

The CHANGELOG entry is release-note-ready. The i18n keys (new_session_creating) appear consistently in the locales touched by the diff. The screenshots in docs/pr-media/2518/ demonstrate the visible idle → pending transition. The change to static/style.css is the two-line disabled-state polish.

The main open question is the coordination with #2519. Both PRs are correct fixes; the issue is they shouldn't both land.