[mouryabalabhadra]

Problem

A ThoughtSpot analytical session belongs to the Org it was created in. After an Org switch mid-chat, the old session rejects new questions (HTTP 400) and reading it returns 422 "Invalid org id", so the agent opens a new session. The chat-history example stored one session id per chat, numbered charts across the whole chat, and assumed one ThoughtSpot message per reply. On reopen, charts from the second session were looked up in the first one: they came back as the wrong chart or were silently dropped. The one-message-per-reply assumption also dropped charts whenever the agent retried inside a reply.

Change (mcp/python-react-agent-simple-ui)

• Per-chart session: every answer / Show work query event carries the session it was polled from; reply rows and answer placeholders store it. Charts are numbered within their own session on reopen.
• Per-session question counts: a new session_message SSE event (ignored by the UI) fires each time ThoughtSpot accepts a send_session_message. Replies store ts_message_counts ({session: n}), so failed/cancelled turns, greetings (0) and retries (2+) pair correctly with ThoughtSpot's messages.
• Newest session wins: a later create_analysis_session replaces the chat's current session, so follow-ups go straight to it.
• Failure handling: a session ThoughtSpot will not return (4xx, e.g. another Org) keeps its placeholders, so the Visual Embed SDK shows "This answer could not be loaded."; a 5xx/timeout retries once and then returns 503 instead of guessing.
• Security: only sessions the conversation created are trusted as chart sessions (the poll's id comes from the model); ids are format-checked and URL-escaped; the work-answers endpoint rejects sessions the chat never used; deleting a chat clears its trust set.
• Migration: additive only (turns.analytical_session_id, turns.ts_message_counts), in one transaction; older replies are pinned once to the chat's session and count as one question.
• Client: stored charts and Show work loads use their own session.
• README: plain-language "How chat history works" with a worked example of one chat across two Orgs; updated storage, endpoints, SSE events and limits.

SDK side (doc-only): thoughtspot/visual-embed-sdk#748.

Testing

• Live on a multi-Org cluster (Orgs switched by minting org-scoped tokens): reply 1 in Org A, replies 2-3 in Org B. Reopened in Org B: reply 1 shows the SDK notice, replies 2-3 render their own charts; reopened in Org A: the reverse, nothing dropped.
• Live: greeting + question + follow-up; a turn cancelled after ThoughtSpot accepted the question, then a follow-up (each chart lands on the reply that asked for it); a reply where the agent retried; Show work expansion; malformed/foreign session ids rejected (404).
• Live: the server's message list (/api/rest/2.0/ai/agent/conversations/{id}/messages) and the SDK's (/conversation/v2/{id}/public) return the same final answers in the same order.
• 22 offline pytest cases (reconcile per session, counts, retries, greetings, two-session replies, 4xx vs 5xx, trust, raw-update tagging, migration on a copy of a real DB, run twice). They are not part of this PR; the example has no test suite.
• Client tsc --noEmit passes.

Known limit: chats saved before this change that already spanned two sessions, or had retries, cannot be repaired (nothing recorded which reply used which session).

🤖 Generated with Claude Code