Skip to content

fix(chat): refresh agent instances when a thread mints one - #111

Merged
vitramir merged 1 commit into
mainfrom
fix/refresh-agent-instances-on-new-thread
Aug 9, 2026
Merged

vitramir merged 1 commit into
mainfrom
fix/refresh-agent-instances-on-new-thread

Conversation

@vitramir

@vitramir vitramir commented Aug 9, 2026 •

Copy link
Copy Markdown
Contributor

Problem

Starting a new thread showed (unknown participant) in the sidebar row and the header until the page was reloaded.

Threads mints a fresh agent instance for every agent added to a thread (createAgentInstance in threads/internal/server/server.go), so the thread CreateThread returns carries an instance id the cached agent-instances list has never seen. useCreateChat only invalidated ['chats','list'], and useAgentInstances has no refetch trigger beyond a mount, so the name only appeared after a reload.

Follow-up to 1cc1026, which made existing instances resolve; this makes newly minted ones resolve too.

Change

  • useCreateChat also invalidates ['agent-instances'].
  • Threads that arrive from elsewhere (an agent opening one with you, a participant someone else adds) have no such hook, so an unresolved participant id triggers one instance refetch, tracked in a ref so an id that stays unresolvable cannot loop. Gated on the batch-users fetch settling so pending human participants do not fire a spurious call.

Verification

  • New unit test on useCreateChat asserting both invalidations.
  • pnpm test 58/58, pnpm typecheck, pnpm lint all clean.
  • Deployed to the local VM from source via devspace dev (chat.agyn.dev serves the dev tree); browser check done by the author, not automated.

Threads mints a fresh instance for every agent added to a thread, so the thread
CreateThread returns names an id the cached instance list has never seen. Chat
creation only invalidated the thread list, so the new row and its header fell
back to (unknown participant) until a reload refetched the instances.

Creating a chat now invalidates the instance list too. Threads that arrive from
elsewhere -- an agent opening one with you, or a participant someone else adds
-- have no such hook, so an unresolved participant id triggers one refetch as
well, tracked in a ref so an id that stays unresolvable cannot loop.
@vitramir
vitramir requested a review from a team as a code owner August 9, 2026 16:49
@vitramir
vitramir merged commit 4c31623 into main Aug 9, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant