ChatPanel profile selector can mismatch the active external-agent thread #141

Activity

1. mydmdm commented on Aug 27, 2026

   

   Yuqing (mydmdm)

   on Aug 27, 2026

   ContributorAuthor

   More actions

   Additional sanitized evidence from a screenshot

   The affected panel can show a prominent error banner stating that the thread cannot change driver kind, while the profile selector below still displays Chat. The composer remains visible and shows GPT-5.6 Sol with Auto mode selected.

   This supports the report's core symptom: thread/panel state and the profile/driver selection can become inconsistent after rehydration or refresh. Thread identifiers and other potentially identifying details from the screenshot are intentionally omitted.
2. mydmdm commented on Sep 11, 2026

   

   Yuqing (mydmdm)

   on Sep 11, 2026

   ContributorAuthor

   More actions

   Code-level finding from a current reproduction (huabu dev displayed as Chat)

   The server-side Agent Node creation path appears correct: apps/server/src/modules/agent/agent-node.service.ts resolves the selected Profile and creates the Question node with an external agentBinding (profileId + alias) and agentBindingPolicy: 'fixed'.

   The mismatch is introduced by Web state ownership/hydration:

   • ChatPanel reads agentBinding from chatStore via selectThreadBinding(state, threadId).
   • chatStore.threadOf() returns DEFAULT_BINDING = { kind: 'internal' } whenever that thread has no cached/persisted binding, which renders as Chat.
   • Question-owned thread metadata is deliberately made ephemeral, so after reload its binding is expected to come from the Question/Agent node rather than bindingByThread.
   • Opening a node interactively calls enterQuestionConversation(..., data.agentBinding, ...), which seeds the store before mounting the panel. A Preview Workspace tab restored directly after refresh does not pass through that entry path.
   • The restored ChatPanel therefore initially uses the internal default and only later attempts to repair it in a useEffect from conversationOwnerSource.agentBinding when agentBindingPolicy === 'fixed'.
   • useChatHistory hydrates messages but does not hydrate the thread binding. If the conversation owner is temporarily unavailable/stale during Canvas or World-reference hydration, the repair effect has no authoritative binding and the selector can remain Chat despite the correct thread/history.

   This also explains why the symptom is associated with refresh/resume and long-lived panels rather than new interactive opens.

   Suggested fix direction

   For a fixed Agent Node, derive the effective binding synchronously from the authoritative conversation owner (fixedAgentBinding ?? cachedThreadBinding) and use that value consistently for the selector, title, ACP hooks, and send path. The store synchronization effect can remain a cache update, but should not be the correctness boundary. Restored tabs should also be covered where the thread cache is empty and owner hydration arrives after the first render.

   Regression coverage

   Add a test that mounts/restores a Question/Agent Preview tab with:

   • an empty chatStore binding cache,
   • a fixed external node binding for huabu dev, and
   • owner data arriving after the initial render.

   The selector may show a neutral loading state before owner resolution, but must never identify the fixed external thread as Chat, and all downstream ACP behavior must use the fixed binding.
3. cxxxxxn (cxxxxxn)

   closed this as completedin #182on Sep 14, 2026