@assistant-ui/mcp-docs-server 0.2.3 → 0.3.0

package/.docs/raw/docs/runtimes/concepts/threads.mdx

@@ -1,513 +0,0 @@
----
-title: Threads
-description: Single-thread, cloud, and custom-database thread management.
----
-
-Every assistant-ui runtime starts with a single in-memory thread. Multi-thread support is added through one of three mechanisms depending on which runtime you are using and where you want threads to live.
-
-## Single thread (default)
-
-With no thread configuration, the runtime renders one thread that resets when the page reloads. Fine for prototypes, demos, and stateless interactions.
-
-If you only want session persistence (single thread, durable across reloads), provide a [history adapter](/docs/runtimes/concepts/adapters#history-adapter) instead of going to multi-thread.
-
-## Multi-thread paths
-
-Three options. Choose based on what you want to own.
-
-| Path | Runtime | Who owns thread metadata | Best for |
-| --- | --- | --- | --- |
-| AssistantCloud | LocalRuntime and adapters built on it | assistant-cloud | You want it managed; auth, sync, persistence handled |
-| RemoteThreadListRuntime | LocalRuntime and adapters built on it | Your database | You have your own backend and want full control |
-| ExternalStoreThreadListAdapter | ExternalStoreRuntime only | Your store | You keep state in redux, zustand, etc. |
-
-## AssistantCloud
-
-`AssistantCloud` is the managed multi-thread service. Pass an instance to `useLocalRuntime` (or any adapter built on it) and threads, persistence, sync, and titles are handled for you.
-
-```tsx
-import { useLocalRuntime } from "@assistant-ui/react";
-import { AssistantCloud } from "assistant-cloud";
-
-const cloud = new AssistantCloud({
-  baseUrl: process.env.NEXT_PUBLIC_ASSISTANT_BASE_URL,
-  anonymous: true,
-});
-
-const runtime = useLocalRuntime(modelAdapter, { cloud });
-```
-
-Framework adapters take `cloud` directly. `AISDKThreads({ cloud })` is the store-entry list for `AuiConfig` hosts. It mounts only the visible thread, so a switch cancels an in-flight run and that exchange is not persisted.
-
-```tsx
-const runtime = useChatRuntime({ cloud });
-const threads = AISDKThreads({ cloud });
-const runtime = useLangGraphRuntime({ cloud /* stream, load, ... */ });
-const runtime = useAdkRuntime({ cloud, stream });
-```
-
-See the [cloud documentation](/docs/cloud) for setup, auth, and self-host options.
-
-## RemoteThreadListRuntime (custom database)
-
-`useRemoteThreadListRuntime` lets you back the thread list with any database while keeping the per-thread runtime simple. You provide a `RemoteThreadListAdapter` describing how to list, create, rename, archive, and delete threads. Keep that adapter reference stable across renders (module scope or `useMemo`). Replacing it reloads the list and drops cached threads that are not in the replacement page.
-
-Works with any `LocalRuntime`-based runtime, including framework adapters that build on it (`ai-sdk`, `react-google-adk`, `react-a2a`, `useDataStreamRuntime`).
-
-```tsx title="app/MyProvider.tsx"
-"use client";
-
-import {
-  AssistantRuntimeProvider,
-  useLocalRuntime,
-  useRemoteThreadListRuntime,
-  type RemoteThreadListAdapter,
-} from "@assistant-ui/react";
-import { createAssistantStream } from "assistant-stream";
-import { modelAdapter } from "./model-adapter";
-
-const adapter: RemoteThreadListAdapter = {
-  async list() {
-    const threads = await fetch("/api/threads").then((r) => r.json());
-    return {
-      threads: threads.map((t: any) => ({
-        status: t.archived ? "archived" : "regular",
-        remoteId: t.id,
-        title: t.title,
-      })),
-    };
-  },
-  async initialize(localId) {
-    const t = await fetch("/api/threads", {
-      method: "POST",
-      body: JSON.stringify({ localId }),
-    }).then((r) => r.json());
-    return { remoteId: t.id };
-  },
-  async rename(remoteId, title) {
-    await fetch(`/api/threads/${remoteId}`, {
-      method: "PATCH",
-      body: JSON.stringify({ title }),
-    });
-  },
-  async archive(remoteId) {
-    await fetch(`/api/threads/${remoteId}/archive`, { method: "POST" });
-  },
-  async unarchive(remoteId) {
-    await fetch(`/api/threads/${remoteId}/unarchive`, { method: "POST" });
-  },
-  async delete(remoteId) {
-    await fetch(`/api/threads/${remoteId}`, { method: "DELETE" });
-  },
-  async fetch(remoteId) {
-    const t = await fetch(`/api/threads/${remoteId}`).then((r) => r.json());
-    return {
-      status: t.archived ? "archived" : "regular",
-      remoteId: t.id,
-      title: t.title,
-    };
-  },
-  async generateTitle(remoteId, messages) {
-    return createAssistantStream(async (controller) => {
-      const { title } = await fetch(`/api/threads/${remoteId}/title`, {
-        method: "POST",
-        body: JSON.stringify({ messages }),
-      }).then((r) => r.json());
-      controller.appendText(title);
-    });
-  },
-};
-
-export function MyProvider({ children }: { children: React.ReactNode }) {
-  const runtime = useRemoteThreadListRuntime({
-    runtimeHook: () => useLocalRuntime(modelAdapter),
-    adapter,
-  });
-  return (
-    <AssistantRuntimeProvider runtime={runtime}>
-      {children}
-    </AssistantRuntimeProvider>
-  );
-}
-```
-
-### Persisting messages
-
-`RemoteThreadListAdapter` only manages thread metadata. Per-thread history and attachments are a separate seam with two faces:
-
-- `unstable_useAdapters` is a hook. The `RemoteThreadList` store entry calls it inside the client tree, so any `createAssistantClient` host gets the same adapters as a React hook host. `useRemoteThreadListRuntime` also calls it when `unstable_Provider` is omitted.
-- `unstable_Provider` is a React component. `useRemoteThreadListRuntime` renders it when present. The store entry ignores it.
-
-On the store entry, wrap the thread factory with `withKey` so the thread remounts on a switch. History adapters load once per mount. An unkeyed factory keeps one instance, and the next thread's messages never appear.
-
-```tsx
-import { withKey } from "@assistant-ui/tap";
-import { RemoteThreadList } from "@assistant-ui/react";
-
-threads: RemoteThreadList({
-  adapter,
-  thread: (id) => withKey(id, MyThread({ threadId: id })),
-}),
-```
-
-Share one hook between both faces:
-
-```tsx
-import {
-  RuntimeAdapterProvider,
-  useAui,
-  type RemoteThreadListAdapter,
-  type ThreadHistoryAdapter,
-} from "@assistant-ui/react";
-import { useMemo } from "react";
-
-function useThreadListAdapters() {
-  const aui = useAui();
-  const history = useMemo<ThreadHistoryAdapter>(
-    () => ({
-      async load() {
-        const { remoteId } = aui.threadListItem.getState();
-        if (!remoteId) return { messages: [] };
-        const rows = await fetch(
-          `/api/threads/${remoteId}/messages`,
-        ).then((r) => r.json());
-        return { messages: rows.map(toThreadMessage) };
-      },
-      async append({ message, parentId }) {
-        const { remoteId } = await aui.threadListItem.initialize();
-        await fetch(`/api/threads/${remoteId}/messages`, {
-          method: "POST",
-          body: JSON.stringify({ message, parentId }),
-        });
-      },
-    }),
-    [aui],
-  );
-  return useMemo(() => ({ history }), [history]);
-}
-
-const adapterWithHistory: RemoteThreadListAdapter = {
-  // ...metadata methods above...
-  unstable_useAdapters: useThreadListAdapters,
-  unstable_Provider({ children }) {
-    const adapters = useThreadListAdapters();
-    return (
-      <RuntimeAdapterProvider adapters={adapters}>
-        {children}
-      </RuntimeAdapterProvider>
-    );
-  },
-};
-```
-
-<Callout type="warn">
-`unstable_Provider` must render `children` synchronously on first commit. Do not gate `children` behind a loading state, suspense, or `useEffect`. If you need to load data before the thread is usable, do it inside an always-rendered child (for example via the history adapter), not by withholding `children`.
-</Callout>
-
-### Avoiding the first-message race
-
-`append` may be called before the thread record exists in your backend. Always await `aui.threadListItem.initialize()` before writing:
-
-```ts
-async append({ message, parentId }) {
-  const { remoteId } = await aui.threadListItem.initialize();
-  await saveMessage(remoteId, parentId, message);
-}
-```
-
-`initialize()` is safe to call multiple times. It always resolves to the same `remoteId` for the active thread.
-
-The same rule applies to a custom external store's dispatch. The runtime does not hold `onNew` or `onEdit` until the thread record exists (that would keep the user's message off screen for the whole roundtrip), so a handler that talks to a backend keyed by the remote identity must await `initialize()` itself:
-
-```ts
-onNew: async (message) => {
-  const { remoteId } = await aui.threadListItem.initialize();
-  await sendToBackend(remoteId, message);
-},
-```
-
-### Reloading after async authentication
-
-If your adapter depends on a user that resolves asynchronously (oidc, `next-auth`, `better-auth`), the initial `list()` may run before the user is available. Call `aui.threads.reload()` after auth completes:
-
-```tsx
-function ReloadOnAuth() {
-  const aui = useAui();
-  const { isLoading, user } = useAuth();
-  useEffect(() => {
-    if (!isLoading && user) aui.threads.reload();
-  }, [isLoading, user?.id]);
-  return null;
-}
-```
-
-`reload()` discards in-flight responses from superseded calls, so it is safe to invoke on every auth transition. On the `RemoteThreadList` store entry, a recreated adapter object is a no-op until you call `reload()`. `reload()` against the same instance refreshes the list and keeps the open thread. `reload()` after a different adapter instance resets selection and cached records, then loads the replacement store.
-
-### Refetching the open thread
-
-`reload()` against the same adapter instance re-runs `list()`, which refreshes thread list metadata only. It does not touch the messages of the thread the user is looking at. When the open thread's server state changes out of band, so that nothing arrives over the stream (a human-in-the-loop interrupt raised by another process, a stalled stream, a status change picked up by polling), call `aui.threads.reloadMainThread()`:
-
-```tsx
-function RefetchOnInterrupt({ status }: { status: string }) {
-  const aui = useAui();
-  useEffect(() => {
-    if (status !== "interrupted") return;
-    aui.threads.reloadMainThread().catch(reportError);
-  }, [status]);
-  return null;
-}
-```
-
-What the promise means depends on the path. On the remount path, it resolves as soon as the replacement runtime attaches, which happens before that runtime's `load()` has started, so awaiting it does not mean the thread is fresh and a failed load cannot reach the caller. On the in-place path, it settles with the refetch itself and rejects when it fails, which is why the example above still handles the rejection.
-
-A thread that has not been sent yet is left alone because it holds no remote state.
-
-What happens to a run in progress depends on the path. The remount path drops the runtime that was rendering the run; whether the run itself stops is up to that hook's unmount cleanup, which core cannot enforce. On the in-place path the runtime that declared the capability decides, since core does not stop the run for it. Either way this belongs on an event rather than a short timer: drive it from a state change like the one above, or skip the call while `useAuiState((s) => s.thread.isRunning)` is true.
-
-How the refetch happens depends on the runtime, in one of three ways. When it declares the capability, the thread runtime is reused: composer drafts survive, existing messages stay rendered while the fresh state loads, and the returned promise settles with the refetch, rejecting if it fails. A remote thread list without the capability remounts the runtime hook instead, which re-runs `load()` at the cost of discarding unsent composer input, and resolves once the new runtime attaches. The single and in-memory thread lists have no hook to remount: they take the in-place path when their tap `ExternalThread` was given `onRefetchThread`, and resolve without doing anything when it was not.
-
-`useAuiState((s) => s.thread.capabilities.refetchThread)` reports which of those you would get, in place or not. It is not a signal for whether to offer a refresh at all: it is false on the remount path, where the call still does the work, and false again where the call does nothing.
-
-Both the LangGraph and Google ADK adapters register the in-place refetch capability when their runtime hook receives a `load` function; without one they fall back to the remount path. The Eve adapter registers it when the installed `eve` exposes `resume()` (0.44.1 and later), with no option to pass; on older releases it falls back like any other adapter, which for the single and in-memory thread lists it is usually paired with means the call resolves without doing anything. A refetch that lands during a run also settles differently across the three: LangGraph and Google ADK issue the load right away, so the promise settles at fetch latency and each decides on arrival how much of the snapshot a racing run leaves standing, while Eve queues the replay behind the in-flight turn, so its promise settles only once that turn parks. Other remote adapters take the remount path unless they provide the capability themselves.
-
-For an external store runtime, declare it with `onRefetchThread`, which is unrelated to `onReload` (that one re-generates an assistant message); the tap `ExternalThread` accepts the same prop:
-
-```ts
-useExternalStoreRuntime({
-  messages,
-  onNew,
-  onRefetchThread: async () => {
-    setMessages(await fetchMessages(threadId));
-  },
-});
-```
-
-### Paginating the thread list
-
-If your backend returns thread pages, return a `nextCursor` from `list()` and consume `aui.threads.hasMore` plus `aui.threads.loadMore()` in the UI. The runtime threads `params.after` back through `list()` on every `loadMore()`; the initial call passes no `params`, so treat a missing `after` as "first page". `reload()` resets the cursor so the next load starts from page 1 again.
-
-```ts title="threadListAdapter.ts (excerpt)"
-async list({ after } = {}) {
-  const url = new URL("/api/threads", location.origin);
-  if (after) url.searchParams.set("after", after);
-  const response = await fetch(url);
-  const { threads, next_cursor } = await response.json();
-  return {
-    threads: threads.map((thread) => ({
-      remoteId: thread.id,
-      status: thread.is_archived ? "archived" : "regular",
-      title: thread.title ?? undefined,
-    })),
-    nextCursor: next_cursor ?? undefined,
-  };
-},
-```
-
-For a button-driven UI, drop `<ThreadListPrimitive.LoadMore>` at the bottom of your list. It ships disabled while the runtime is loading or when no `nextCursor` is available. To trigger it on scroll instead, wrap the same primitive in an `IntersectionObserver` at the application layer; assistant-ui leaves visibility-driven loading to userland by design.
-
-```tsx title="ThreadList.tsx"
-import {
-  ThreadListPrimitive,
-  ThreadListItemPrimitive,
-} from "@assistant-ui/react";
-
-export function ThreadList() {
-  return (
-    <ThreadListPrimitive.Root>
-      <ThreadListPrimitive.Items>
-        {() => (
-          <ThreadListItemPrimitive.Root>
-            <ThreadListItemPrimitive.Trigger>
-              <ThreadListItemPrimitive.Title />
-            </ThreadListItemPrimitive.Trigger>
-          </ThreadListItemPrimitive.Root>
-        )}
-      </ThreadListPrimitive.Items>
-      <ThreadListPrimitive.LoadMore>Load more</ThreadListPrimitive.LoadMore>
-    </ThreadListPrimitive.Root>
-  );
-}
-```
-
-A few invariants worth knowing when wiring a custom UI on top of `loadMore()`:
-
-- **Empty-string cursors collapse to "no more pages".** `nextCursor: ""` is treated the same as `nextCursor: undefined`, so an off-by-one in your backend that returns an empty cursor will not loop forever.
-- **Concurrent `loadMore()` calls are deduped.** The runtime keeps a single in-flight promise per page, so calling `loadMore()` from a sentinel and a button at the same time issues only one network request.
-- **Page errors are swallowed.** If `list({ after })` rejects, the cursor is preserved and the next `loadMore()` retries with the same `after` value. The promise returned to the caller resolves regardless. Surface adapter errors yourself if you need user-visible feedback.
-
-### Adapter contract
-
-<ParametersTable
-  type="RemoteThreadListAdapter"
-  parameters={[
-    {
-      name: "list",
-      type: "(params?: { after?: string }) => Promise<{ threads: RemoteThreadMetadata[]; nextCursor?: string }>",
-      description:
-        "Hydrate threads on mount. Each thread must include status and remoteId; title, externalId, and custom are optional. Return a `nextCursor` to enable `aui.threads.loadMore()`; the runtime will pass it back as `params.after` on the next call.",
-      required: true,
-    },
-    {
-      name: "initialize",
-      type: "(localId: string) => Promise<{ remoteId: string; externalId?: string }>",
-      description:
-        "Create a new remote record when the user starts a conversation. Return the canonical ids.",
-      required: true,
-    },
-    {
-      name: "rename",
-      type: "(remoteId: string, title: string) => Promise<void>",
-      description: "Persist title changes from the UI.",
-      required: true,
-    },
-    {
-      name: "updateCustom",
-      type: "(remoteId: string, custom: Record<string, unknown> | undefined) => Promise<void>",
-      description:
-        "Optional. Persist replacement custom metadata from `aui.threadListItem.updateCustom(custom)`.",
-    },
-    {
-      name: "archive",
-      type: "(remoteId: string) => Promise<void>",
-      description: "Mark thread archived.",
-      required: true,
-    },
-    {
-      name: "unarchive",
-      type: "(remoteId: string) => Promise<void>",
-      description: "Restore an archived thread.",
-      required: true,
-    },
-    {
-      name: "delete",
-      type: "(remoteId: string) => Promise<void>",
-      description: "Permanently remove the thread.",
-      required: true,
-    },
-    {
-      name: "fetch",
-      type: "(threadId: string) => Promise<RemoteThreadMetadata>",
-      description: "Fetch metadata for a single thread when switching.",
-      required: true,
-    },
-    {
-      name: "generateTitle",
-      type: "(remoteId: string, messages: readonly ThreadMessage[]) => Promise<AssistantStream>",
-      description:
-        "Stream a title back. Use createAssistantStream and controller.appendText.",
-      required: true,
-    },
-    {
-      name: "unstable_Provider",
-      type: "RemoteThreadListProviderComponent",
-      description:
-        "Optional React wrapper rendered around each active thread by useRemoteThreadListRuntime when present. Inject thread-scoped adapters here. Omit it to let that host use unstable_useAdapters.",
-    },
-    {
-      name: "unstable_useAdapters",
-      type: "() => RuntimeAdapters | null | undefined",
-      description:
-        "Optional hook called by the RemoteThreadList store entry, and by useRemoteThreadListRuntime when unstable_Provider is omitted. Per-thread history requires the thread factory to be keyed with withKey.",
-    },
-  ]}
-/>
-
-### Custom metadata
-
-`RemoteThreadMetadata` includes an optional `custom?: Record<string, unknown>` slot for backend-specific fields (timestamps, owner ids, workspace ids, tags, model name). Whatever you return from `list()` and `fetch()` flows through to the thread list item state and is reachable from any UI primitive via `useAuiState`.
-
-```ts
-type MyThreadMetadata = RemoteThreadMetadata & {
-  readonly custom: {
-    readonly createdAt: string;
-    readonly ownerId: string;
-  };
-};
-```
-
-```tsx
-import { useAuiState } from "@assistant-ui/react";
-
-function ThreadListItemMeta() {
-  const custom = useAuiState(
-    (s) => s.threadListItem.custom as MyThreadMetadata["custom"] | undefined,
-  );
-  return (
-    <span>
-      {custom?.ownerId} · {custom?.createdAt}
-    </span>
-  );
-}
-```
-
-`custom` is preserved across `rename`, `archive`, `unarchive`, and `generateTitle`. To replace it from your UI, implement `RemoteThreadListAdapter.updateCustom` and call `aui.threadListItem.updateCustom(custom)`. The cloud adapter persists this through `cloud.threads.update(threadId, { metadata })`. If your adapter mutates thread metadata through a separate application path, return the updated values from `fetch()` or call `aui.threads.reload()` to re-run `list()`.
-
-## ExternalStoreThreadListAdapter
-
-For `ExternalStoreRuntime` users only. Wires multi-thread support into an external state store.
-
-```tsx
-const threadListAdapter: ExternalStoreThreadListAdapter = {
-  threadId: currentThreadId,
-  threads: threadList.filter((t) => t.status === "regular"),
-  archivedThreads: threadList.filter((t) => t.status === "archived"),
-  onSwitchToNewThread: () => {
-    /* create + switch */
-  },
-  onSwitchToThread: (id) => setCurrentThreadId(id),
-  onRename: (id, title) => {
-    /* update */
-  },
-  onArchive: (id) => {
-    /* archive */
-  },
-  onUnarchive: (id) => {
-    /* unarchive */
-  },
-  onDelete: (id) => {
-    /* delete */
-  },
-};
-
-const runtime = useExternalStoreRuntime({
-  messages: threads.get(currentThreadId) ?? [],
-  setMessages: (messages) =>
-    setThreads((m) => new Map(m).set(currentThreadId, messages)),
-  onNew,
-  adapters: { threadList: threadListAdapter },
-});
-```
-
-Unlike `RemoteThreadListAdapter`, this adapter is synchronous and inline. You keep thread metadata and messages in your own store; the runtime just renders what you provide.
-
-<Callout type="warn">
-The runtime's `currentThreadId` and your store's selected thread must stay in sync. Mismatched thread ids cause messages to appear in the wrong thread or vanish entirely. Centralize thread id state in a context, never in component-local state.
-</Callout>
-
-## Choosing
-
-Ask three questions in order:
-
-1. **Do you want it managed?** Use `AssistantCloud`. You do not write database code.
-2. **Do you have your own backend?** Use `RemoteThreadListRuntime` if you are on `LocalRuntime` (or any adapter built on it). You implement the adapter, you own the data.
-3. **Are you on `ExternalStoreRuntime`?** Use `ExternalStoreThreadListAdapter`. Threads live in your store next to messages.
-
-## Related
-
-<Cards>
-  <Card
-    title="Adapters"
-    description="The shared adapter contracts (attachments, history, speech, feedback)."
-    href="/docs/runtimes/concepts/adapters"
-  />
-  <Card
-    title="Architecture"
-    description="The three-layer runtime model and how threads flow through it."
-    href="/docs/runtimes/concepts/architecture"
-  />
-  <Card
-    title="AssistantCloud"
-    description="The managed multi-thread service."
-    href="/docs/cloud"
-  />
-</Cards>