@iloveagents/foundry-web-shell 0.2.0 → 0.2.2

package/CHANGELOG.md

@@ -1,5 +1,56 @@
 # @iloveagents/foundry-web-shell
 
+## 0.2.2
+
+### Patch Changes
+
+- 8184a8c: shell: URL is authoritative for the runtime threadId — fixes
+  resume-creates-new-conversation race
+
+  `ChatConversationAwareRuntime` previously computed
+  `effectiveThreadId = sticky ?? urlMatch ?? freshIdRef.current`.
+  When the user navigated from one chat to another via a Recents
+  click, the synchronous render that followed the URL change had:
+  - `urlMatch = B` (read from the now-updated `useLocation`)
+  - `sticky = A` (the active-chat-store hadn't been updated by
+    `useTrackActiveChatFromUrl`'s `useEffect` yet — effects run
+    AFTER the commit phase)
+
+  `sticky ?? urlMatch` picked `A` (the previous chat). The AG-UI
+  adapter was constructed with `threadId = A`. The first message the
+  user sent went to `/api/agent` with `thread_id = A`, the middleware
+  created a new row keyed by `A`... wait actually no, here's what
+  happens — the runtime mints a fresh runner UUID when given a
+  mismatched threadId; that fresh UUID became a new conversation row,
+  appearing as "Untitled chat" at the top of the sidebar while the
+  URL still said `/chat/B`. Two active-looking dots: one for `B`
+  (NavLink URL match), one for the new row (statusDot from the
+  updated active-chat-store after the lazy ensure ran).
+
+  Swap the priority: `urlMatch ?? sticky ?? freshIdRef.current`. The
+  URL is authoritative whenever it's set (i.e. on `/chat/<id>`
+  routes), eliminating the stale-sticky race entirely. `sticky` is
+  still consulted as the second-priority fallback for non-chat
+  routes (`/spaces`, `/tasks`) so the popout chat stays "live" while
+  the user browses workspaces — that's the original purpose of
+  `useStickyConversationId` and it's preserved.
+
+- Updated dependencies [395f0cd]
+- Updated dependencies [1ba01ef]
+- Updated dependencies [8184a8c]
+  - @iloveagents/foundry-web-ui@0.2.2
+  - @iloveagents/foundry-agent@0.2.2
+  - @iloveagents/foundry-web-primitives@0.2.2
+
+## 0.2.1
+
+### Patch Changes
+
+- No source changes. Bumped in lock-step with the fixed group so the
+  whole group can publish at a version number that's free across all
+  four packages. (`shell@0.2.0` already published cleanly; this is a
+  follow-the-group patch bump.)
+
 ## 0.2.0
 
 ### Minor Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iloveagents/foundry-web-shell",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "license": "SEE LICENSE IN LICENSE",
   "type": "module",
   "types": "./src/index.ts",
@@ -19,9 +19,9 @@
     "zustand": "^5.0.0"
   },
   "dependencies": {
-    "@iloveagents/foundry-web-primitives": "0.2.0",
-    "@iloveagents/foundry-web-ui": "0.2.0",
-    "@iloveagents/foundry-agent": "0.2.0"
+    "@iloveagents/foundry-agent": "0.2.2",
+    "@iloveagents/foundry-web-primitives": "0.2.2",
+    "@iloveagents/foundry-web-ui": "0.2.2"
   },
   "devDependencies": {
     "typescript": "~5.9.3",

package/src/shell-app.tsx

@@ -283,9 +283,39 @@ function RuntimeBody({
   prevStickyRef.current = sticky;
 
   // Effective id seen by AGUIRuntimeProvider — always defined.
-  //   sticky (current conversation) wins, else fall back to the
-  //   shell-minted UUID for fresh chats.
-  const effectiveThreadId: string = sticky ?? urlMatch ?? freshIdRef.current;
+  //
+  // Priority order matters and is intentional:
+  //   1. ``urlMatch`` — when the user is on ``/chat/<id>`` the URL is
+  //      ALWAYS the authoritative conversation. This MUST come before
+  //      ``sticky`` because of a stale-render race on cross-chat
+  //      navigation:
+  //        - User is on ``/chat/A``. ``active-chat-store`` holds ``A``.
+  //          So ``sticky = A``.
+  //        - User clicks a Recents row for ``B`` →
+  //          ``react-router`` updates pathname to ``/chat/B``.
+  //        - On the synchronous render that follows, ``urlMatch`` is
+  //          ``B`` (read from ``useLocation``) but
+  //          ``useTrackActiveChatFromUrl``'s ``useEffect`` hasn't run
+  //          yet — so ``sticky`` is still ``A``.
+  //        - With ``sticky ?? urlMatch`` we'd compute
+  //          ``effectiveThreadId = A``, bind the AG-UI adapter to ``A``,
+  //          and the first message the user sends would create a NEW
+  //          row at ``A``'s old thread id while the URL says ``B``.
+  //          Symptoms: TWO active dots in the sidebar (URL highlights
+  //          row ``B``, the new row's id activates the dot on a
+  //          freshly-appeared "Untitled chat"); resume appears to
+  //          mint a new conversation; messages land on the wrong row.
+  //      Putting ``urlMatch`` first eliminates the race entirely: when
+  //      the URL says we're on chat ``B``, the runtime targets ``B``
+  //      from the very first render, regardless of stale store state.
+  //   2. ``sticky`` — for non-chat URLs (``/spaces``, ``/tasks`` …)
+  //      ``urlMatch`` is ``undefined``. ``sticky`` keeps the popout
+  //      chat "live" while the user browses elsewhere.
+  //   3. ``freshIdRef.current`` — brand-new chat on ``/`` with no
+  //      sticky and no URL match. Pre-minted so the runtime's
+  //      ``threadId`` is defined from the first render (no
+  //      ``undefined → defined`` remount of assistant-ui).
+  const effectiveThreadId: string = urlMatch ?? sticky ?? freshIdRef.current;
 
   const historyAdapterFactory = useCallback<AGUIHistoryAdapterFactory>(
     (args: AGUIChatConversationFactoryArgs) =>