fix(desktop): hold create guard until route catches new session

[stantheman0128]

Summary

Closes #66057

Credit: Stan Shih (@stantheman0128). Developed with AI assistance (Cursor / Grok).

After New Session, the first send could flash the new chat then jump back to the previous one. createBackendSessionForSend updated selection refs and navigated, then cleared creatingSessionRef with setTimeout(0). use-route-resume could then treat the still-old route as stuck and resumeSession the previous chat.

Changes

• Keep creatingSessionRef true until the route and selection agree on the created (or forked) stored session id
• Belt in use-route-resume: if selection/runtime already moved ahead of a stale route, do not resume the old route
• Escape hatches so the guard cannot stick forever: navigate throw, route leaving for a non-pending id, fork catch, and a 3s safety timeout

Related but different: open #66376 covers stale resume at New Chat draft start, not this first-send create-route race.

Verification

`
npx vitest run --project ui src/app/session/hooks/use-route-resume.test.tsx src/app/session/hooks/use-session-actions.test.tsx

Test Files 2 passed | Tests 36 passed

`

`
python scripts/check-windows-footguns.py --diff HEAD~2

clean

`

Made with Cursor

[teknium1]

Thanks for tracing the create/route race; current main still has the delayed guard release at apps/desktop/src/app/session/hooks/use-session-actions/index.ts:344-348, and its stale-route self-heal can resume the old route at apps/desktop/src/app/session/hooks/use-route-resume.ts:137-150.

Problems

• The new suppression at apps/desktop/src/app/session/hooks/use-route-resume.ts:150 remains active after the proposed 3s timeout if navigation never moves from A to B: selection and active refs remain B, so stuckOnRoutedSession stays false. That makes the claimed timeout recovery ineffective; ChatView keeps the route/selection mismatch in its loading state (apps/desktop/src/app/chat/index.tsx:281-315).

Suggested changes

• Tie this suppression to an active pending-create state, or reconcile route/selection when the timeout releases the guard. Add a regression test covering a route that never catches up and asserting recovery, not only guard release.

Automated hermes-sweeper review.

[teknium1]

The 3s release does not restore recovery if navigation never reaches B: the route remains A while selected/active refs remain B, so this condition stays true and stuckOnRoutedSession never resumes A. Scope this suppression to pending creation or reconcile state when the timeout fires; add a test for that composed timeout path.

[stantheman0128]

Thanks for flagging the timeout recovery hole.

You were right: clearing creatingSessionRef after 3s did not help when selection/active stayed on B and the route never left A. selectionMovedAheadOfRoute kept stuckOnRoutedSession false, so ChatView stayed on the route/selection mismatch loader.

Pushed 270f9ecb8 on this branch (Stan Shih / stantheman0128, with Cursor assist):

• Scope that suppression to an active pending-create hold (creatingSessionRef) only
• On the safety timeout, retry navigate to the pending session, then release the guard so route resume can still self-heal if the router stays stuck
• Regression test: never-catches-up shape asserts resumeSession(A) (recovery), not only guard release; the timeout test also asserts the retry navigate

Evidence:

npx vitest run src/app/session/hooks/use-route-resume.test.tsx src/app/session/hooks/use-session-actions.test.tsx

 RUN  v4.1.9

 Test Files  2 passed (2)
      Tests  37 passed (37)

[stantheman0128]

Closing as author to bring our open PRs on hermes-agent back within a healthy throttle (we had 10 open with only sweeper keep_open and no concrete maintainer change requests for days).

Keeping three Windows-focused PRs open for now:

• fix(desktop): avoid Explorer DnD image preview freeze on Windows #66546 (Explorer DnD image preview freeze on Windows)
• fix(tools): translate MSYS paths to Windows-native before shell lint (#66494) #66524 (MSYS path translation before shell lint)
• fix(browser): keep local Chromium headless on Windows Desktop (#64867) #66523 (local Chromium headless on Windows Desktop)

Happy to reopen this one if a maintainer wants it prioritized. Thanks for the patience.