Generation page: deleting a session mid-generation lets its response resurrect it as an orphaned session

[lourincedaging0-commits]

Capability or area

generation-ui — Generation page, session panel (imagent-ui/app/components/GenerationChat.tsx)

Problem

If a session is deleted while its generation is still in flight, the
background request's eventual response resurrects it as a brand new,
disconnected session once it lands.

deleteSession removes the session from sessions and (if it was the
last one) replaces it with a fresh empty session — but the in-flight
sendPrompt call for the deleted session is untouched and still holds
the old sessionId in closure. When it resolves, appendSessionMessages
runs its "session not found -> create it" branch (meant for the very
first message of a brand new chat) and unconditionally re-inserts a
session with that id:

// GenerationChat.tsx ~line 557
if (!current.some((session) => session.id === sessionId)) {
  return [
    { id: sessionId, title: nextTitle || "New Session", /* ... */ messages: appendedMessages },
    ...current
  ];
}

There is no way to distinguish "this id is genuinely new" from "this id
existed and was explicitly deleted", so a deleted session comes back as
an orphaned "New Session" entry containing only the late-arriving
assistant message, with no user message, no context, and no title.

Reproducible on main (04c818a):

1. Send a prompt in a session; while it's generating, delete that session
   via the trash icon + confirm.
2. The delete correctly replaces it with a fresh empty session.
3. When the deleted session's background response lands, a second,
   orphaned "New Session" entry appears in the sidebar — data the user
   just explicitly told the app to remove.

Proposed change

Inside the approved Generation UI files only
(app/components/GenerationChat.tsx):

• The async completion appends (success and error, after await fetch(...))
  should not be allowed to recreate a session that no longer exists — only
  the initial, synchronous user-message append (the one genuine
  "first message of a brand new chat" case) should be allowed to create a
  session record.
• If the owning session was deleted before the response arrives, drop the
  late response instead of resurrecting the session.

No visual/layout changes — state-management fix only.

Expected agent impact

None — Generation page UI only; no agent, runtime, or benchmark behavior
changes. Deleting a session actually removes it, even if a generation for
it was still running in the background.

[lourincedaging0-commits]

Claiming this — have a fix ready locally, will open the PR once #100 (my currently open Generation UI PR) is resolved, since CONTRIBUTING.md limits contributors to one open Generation UI PR at a time.