@trigger.dev/sdk 4.5.0-rc.5 → 4.5.0-rc.7

package/docs/ai-chat/server-chat.mdx

@@ -0,0 +1,263 @@
+---
+title: "Server-Side Chat"
+sidebarTitle: "Server-Side Chat"
+description: "Use AgentChat to interact with chat agents from server-side code — tasks, webhooks, scripts, or other agents."
+---
+
+import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
+
+<RcBanner />
+
+`AgentChat` lets you chat with agents from server-side code. It works inside tasks (agent-to-agent), request handlers, webhook processors, and scripts.
+
+```ts
+import { AgentChat } from "@trigger.dev/sdk/chat";
+
+const chat = new AgentChat({ agent: "my-agent" });
+const stream = await chat.sendMessage("Hello!");
+const text = await stream.text();
+await chat.close();
+```
+
+## Type-safe client data
+
+Pass `typeof yourAgent` as a type parameter and `clientData` is automatically typed from the agent's `withClientData` schema:
+
+```ts
+import { AgentChat } from "@trigger.dev/sdk/chat";
+import type { myAgent } from "./trigger/my-agent";
+
+const chat = new AgentChat<typeof myAgent>({
+  agent: "my-agent",
+  clientData: { userId: "user_123" }, // ← typed from agent definition
+});
+```
+
+## Conversation lifecycle
+
+Each `AgentChat` instance represents one conversation. The conversation ID is auto-generated or can be set explicitly:
+
+```ts
+// Auto-generated ID
+const chat = new AgentChat({ agent: "my-agent" });
+
+// Explicit ID — useful for persistence or finding the run later
+const chat = new AgentChat({ agent: "my-agent", id: `review-${prNumber}` });
+```
+
+### Sending messages
+
+`sendMessage()` triggers a new run on the first call, then reuses the same run for subsequent messages via input streams:
+
+```ts
+// First message — triggers a new run
+const stream1 = await chat.sendMessage("Review PR #42");
+const review = await stream1.text();
+
+// Follow-up — same run, agent has full context
+const stream2 = await chat.sendMessage("Can you fix the main bug?");
+const fix = await stream2.text();
+```
+
+### Preloading (optional)
+
+If you want the agent to initialize before the first message (e.g., load data, authenticate), call `preload()`. This is optional — `sendMessage()` triggers the run automatically if needed.
+
+```ts
+await chat.preload();
+// Agent's onPreload hook fires now, before user types anything
+const stream = await chat.sendMessage("Hello");
+```
+
+### Closing
+
+Signal the agent to exit its loop gracefully:
+
+```ts
+await chat.close();
+```
+
+Without `close()`, the agent exits on its own when its idle/suspend timeout expires.
+
+## Reading responses
+
+`sendMessage()` returns a `ChatStream` — a typed wrapper around the response.
+
+### Get the full text
+
+```ts
+const stream = await chat.sendMessage("What is Trigger.dev?");
+const text = await stream.text();
+```
+
+### Get structured results
+
+```ts
+const stream = await chat.sendMessage("Research this topic");
+const { text, toolCalls, toolResults } = await stream.result();
+
+for (const tc of toolCalls) {
+  console.log(`Tool: ${tc.toolName}, Input: ${JSON.stringify(tc.input)}`);
+}
+```
+
+### Stream chunks in real-time
+
+```ts
+const stream = await chat.sendMessage("Write a report");
+
+for await (const chunk of stream) {
+  if (chunk.type === "text-delta") {
+    process.stdout.write(chunk.delta);
+  }
+  if (chunk.type === "tool-input-available") {
+    console.log(`Using tool: ${chunk.toolName}`);
+  }
+}
+```
+
+## Stateless request handlers
+
+In a stateless environment (HTTP handler, serverless function), you need to persist and restore the session across requests.
+
+Each chat is backed by a durable Session row that outlives any single run. `AgentChat` exposes the persistable state via `chat.session` (the SSE resume cursor) and surfaces the current run id via the `onTriggered` callback for telemetry / dashboard linking.
+
+```ts
+import { AgentChat } from "@trigger.dev/sdk/chat";
+
+export async function POST(req: Request) {
+  const { chatId, message } = await req.json();
+  const saved = await db.sessions.find({ chatId });
+
+  const chat = new AgentChat({
+    agent: "my-agent",
+    id: chatId,
+    // Restore from previous request — `lastEventId` is the SSE resume
+    // cursor; the underlying Session is keyed on `chatId` so it's
+    // implicit and durable.
+    session: saved ? { lastEventId: saved.lastEventId } : undefined,
+    // Useful for telemetry / dashboard linking. The `runId` is the
+    // current run, which may change across continuations and upgrades.
+    onTriggered: async ({ runId }) => {
+      await db.sessions.upsert({ chatId, runId });
+    },
+    // Persist after each turn for stream resumption
+    onTurnComplete: async ({ lastEventId }) => {
+      await db.sessions.update({ chatId, lastEventId });
+    },
+  });
+
+  const stream = await chat.sendMessage(message);
+  const text = await stream.text();
+
+  return Response.json({ text });
+}
+```
+
+<Info>
+  The Session row is the run manager — a chat that was active yesterday
+  resumes against the same chatId today, even if the original run has
+  long since exited. `AgentChat` (server-side) and `TriggerChatTransport`
+  (browser) both rely on this: send a new message and the server
+  triggers a fresh continuation run on the same session, carrying the
+  conversation forward without losing history or identity.
+</Info>
+
+## Sub-agent tool pattern
+
+`AgentChat` can be used inside an AI SDK tool to delegate work to a durable sub-agent. The sub-agent's response streams as preliminary tool results:
+
+```ts
+import { tool } from "ai";
+import { AgentChat } from "@trigger.dev/sdk/chat";
+import { z } from "zod";
+
+const researchTool = tool({
+  description: "Delegate research to a specialist agent.",
+  inputSchema: z.object({ topic: z.string() }),
+  execute: async function* ({ topic }, { abortSignal }) {
+    const chat = new AgentChat({ agent: "research-agent" });
+    const stream = await chat.sendMessage(topic, { abortSignal });
+    yield* stream.messages();
+    await chat.close();
+  },
+  toModelOutput: ({ output: message }) => {
+    const lastText = message?.parts?.findLast(
+      (p: { type: string }) => p.type === "text"
+    ) as { text?: string } | undefined;
+    return { type: "text", value: lastText?.text ?? "Done." };
+  },
+});
+```
+
+This supports single-turn delegation, multi-turn LLM-driven conversations with persistent sub-agents, and cross-turn state that survives snapshot/restore.
+
+See the [Sub-Agents guide](/ai-chat/patterns/sub-agents) for the full pattern including multi-turn conversations, cleanup, and what the frontend sees.
+
+## Additional methods
+
+### Steering
+
+Send a message during an active stream without interrupting it:
+
+```ts
+await chat.steer("Focus on security issues specifically");
+```
+
+### Stop generation
+
+Abort the current `streamText` call without ending the run:
+
+```ts
+await chat.stop();
+```
+
+### Raw messages
+
+For full control over the UIMessage shape:
+
+```ts
+const rawStream = await chat.sendRaw([
+  {
+    id: "msg-1",
+    role: "user",
+    parts: [
+      { type: "text", text: "Hello" },
+      { type: "file", url: "https://...", mediaType: "image/png" },
+    ],
+  },
+]);
+```
+
+### Reconnect
+
+Resume a stream subscription after a disconnect:
+
+```ts
+const stream = await chat.reconnect();
+```
+
+## AgentChat options
+
+| Option | Type | Default | Description |
+|---|---|---|---|
+| `agent` | `string` | required | The agent task ID to trigger |
+| `id` | `string` | `crypto.randomUUID()` | Conversation ID for tagging and correlation |
+| `clientData` | typed from agent | `undefined` | Client data included in every request |
+| `session` | `ChatSession` (`{ lastEventId?: string }`) | `undefined` | Restore a previous session's SSE resume cursor. The Session row itself is keyed on `chatId` (durable) — no other state to thread. |
+| `onTriggered` | `(event) => void` | `undefined` | Called when a new run is created |
+| `onTurnComplete` | `(event) => void` | `undefined` | Called when a turn's stream ends |
+| `streamTimeoutSeconds` | `number` | `120` | SSE timeout in seconds |
+| `triggerConfig` | `SessionTriggerConfig` | `undefined` | Tags, queue, machine, `maxAttempts`, `idleTimeoutInSeconds`, `basePayload` — folded into `sessions.start({...})` |
+| `baseURL` | `string \| (ctx: { endpoint: "in" \| "out"; chatId: string }) => string` | `apiClientManager.baseURL` | API base URL. String form applies to every endpoint; function form picks per endpoint — useful for routing `.in/append` through an edge proxy while keeping `.out` SSE direct. Defaults to whatever `@trigger.dev/sdk` was configured with (typically `TRIGGER_API_URL`). |
+| `fetch` | `(url: string, init: RequestInit, ctx: { endpoint: "in" \| "out"; chatId: string }) => Promise<Response>` | `undefined` | Per-request fetch override. Invoked for both `.in/append` POSTs and the `.out` SSE GET. Use for header injection, custom retries, or proxy rewrites. |
+
+## ChatStream methods
+
+| Method | Returns | Description |
+|---|---|---|
+| `text()` | `Promise<string>` | Consume stream, return accumulated text |
+| `result()` | `Promise<ChatStreamResult>` | Consume stream, return `{ text, toolCalls, toolResults }` |
+| `messages()` | `AsyncGenerator<UIMessage>` | Yield accumulated UIMessage snapshots (sub-agent pattern) |
+| `[Symbol.asyncIterator]` | `UIMessageChunk` | Iterate over typed stream chunks |
+| `.stream` | `ReadableStream<UIMessageChunk>` | Raw stream for AI SDK utilities |

package/docs/ai-chat/sessions.mdx

@@ -0,0 +1,333 @@
+---
+title: "Sessions"
+sidebarTitle: "Sessions"
+description: "A Session is a stateful execution of an agent, with two-way streaming and durable compute. A single Session can have multiple runs associated with it."
+---
+
+import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
+
+<RcBanner />
+
+**A Session is a stateful execution of an agent.** It includes two-way streaming and durable compute, and a single Session can have multiple runs associated with it.
+
+The **two-way streaming** is a pair of durable streams. The input stream (`.in`) carries incoming user messages to your task. The output stream (`.out`) carries everything the agent produces back to your clients: AI generation parts (text, reasoning, tool calls) and any custom data parts you write.
+
+The **durable compute** is the runs that process those streams. A Session is keyed on your stable id (`externalId` — for chat, the `chatId`) and owns its current run: when a run suspends, idles out, or hands off to a new version, the Session starts or swaps to a fresh run and the streams carry on. Clients keep sending and reading against the same id; they never know a run changed underneath.
+
+```mermaid
+flowchart LR
+  C[Browser / backend clients] -- "user messages" --> IN([Session .in])
+  IN --> R["current run<br/>(runs come and go)"]
+  R -- "text, reasoning, tool calls,<br/>data parts" --> OUT([Session .out])
+  OUT --> C
+```
+
+`chat.agent` is built on Sessions. You can also use them directly for any pattern that needs durable bi-directional streaming across runs: long-lived agent inboxes, multi-step approval flows, server-to-server pipelines that survive worker restarts.
+
+## A minimal example
+
+A task that echoes whatever lands on its input stream, and a backend that starts the session, sends a message, and reads the reply:
+
+```ts trigger/inbox.ts
+import { task, sessions } from "@trigger.dev/sdk";
+
+export const inboxAgent = task({
+  id: "inbox-agent",
+  run: async (payload: { sessionId: string }) => {
+    const session = sessions.open(payload.sessionId);
+
+    while (true) {
+      // Suspends the run (no compute billed) until a record arrives.
+      const next = await session.in.wait<{ text: string }>({ timeout: "1h" });
+      if (!next.ok) return;
+      await session.out.append({ type: "reply", text: `echo: ${next.output.text}` });
+    }
+  },
+});
+```
+
+```ts Your backend
+import { sessions } from "@trigger.dev/sdk";
+
+// Atomically create the session AND trigger its first run.
+await sessions.start({
+  type: "inbox",
+  externalId: userId,
+  taskIdentifier: "inbox-agent",
+  triggerConfig: { basePayload: { sessionId: userId } },
+});
+
+const session = sessions.open(userId);
+await session.in.send({ text: "hello" });
+
+const stream = await session.out.read({ signal: AbortSignal.timeout(30_000) });
+for await (const chunk of stream) {
+  console.log(chunk); // { type: "reply", text: "echo: hello" }
+}
+```
+
+The run can suspend, crash, or be replaced between the `send` and the `read` — the streams are durable, so nothing is lost and the client code doesn't change.
+
+## Sessions and runs
+
+One Session spans many runs over its lifetime. The Session row tracks `currentRunId`; the runs do the work:
+
+- **First run**: created atomically by `sessions.start` (no gap where the session exists but nothing is listening).
+- **Idle suspend**: a run blocked on `in.wait` suspends and frees compute. A new record on `.in` wakes it.
+- **Continuation**: when a run ends (idle timeout, `chat.endRun`, a crash, a version upgrade), the next incoming record triggers a fresh run against the same Session. The new run picks up the streams where the old one left off.
+
+This is what makes a Session the durable identity for a conversation: runs are an execution detail, the Session (and its `externalId`) is what your clients address. See [How it works](/ai-chat/how-it-works) for how `chat.agent` drives this loop.
+
+## When to reach for Sessions directly
+
+`chat.agent` handles 90% of chat-shaped workloads — message accumulation, the turn loop, stop signals, lifecycle hooks. Use the raw `sessions` API when you need any of:
+
+- **Non-chat conversational state**: an agent inbox where each "turn" is a webhook event rather than a UI message.
+- **Server-to-server bi-directional streaming** where an external service produces records the task consumes (and vice-versa) over the same durable channel.
+- **A custom turn loop** where the agent abstraction doesn't fit but you still want session-survival across runs.
+
+For chat use cases, prefer [`chat.agent`](/ai-chat/backend#chat-agent) or [`chat.createSession`](/ai-chat/backend#chat-createsession).
+
+## `sessions` namespace
+
+```ts
+import { sessions } from "@trigger.dev/sdk";
+```
+
+### `sessions.start(body, requestOptions?)`
+
+Atomically create a Session row and trigger its first run. Idempotent on `(env, externalId)` — two concurrent calls with the same `externalId` converge to one session.
+
+```ts
+const { id, runId, publicAccessToken, isCached } = await sessions.start({
+  type: "chat.agent",
+  externalId: chatId,
+  taskIdentifier: "my-chat",
+  triggerConfig: {
+    tags: [`chat:${chatId}`],
+    basePayload: { /* whatever your task's payload shape is */ },
+  },
+});
+```
+
+| Field | Type | Notes |
+|---|---|---|
+| `type` | `string` | Free-form discriminator. `chat.agent` uses `"chat.agent"`. |
+| `externalId` | `string?` | Your stable identity. Cannot start with `session_` (reserved). |
+| `taskIdentifier` | `string` | Task this session triggers runs against. |
+| `triggerConfig` | `SessionTriggerConfig` | Trigger options applied to every run: `tags`, `queue`, `machine`, `maxAttempts`, `idleTimeoutInSeconds`, `basePayload`. |
+| `tags` | `string[]?` | Up to 10 tags on the Session row (separate from `triggerConfig.tags`). |
+| `metadata` | `Record<string, unknown>?` | Arbitrary JSON. |
+| `expiresAt` | `Date?` | Hard retention deadline. |
+
+Returns `CreatedSessionResponseBody`:
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | `string` | Server-assigned `session_*` friendlyId. |
+| `runId` | `string` | The first run created alongside the session. |
+| `publicAccessToken` | `string` | Session-scoped PAT (`read:sessions:{id} + write:sessions:{id}`). |
+| `isCached` | `boolean` | `true` if the session already existed (idempotent upsert). |
+
+### `sessions.retrieve(idOrExternalId, requestOptions?)`
+
+Retrieve a Session by either its server-assigned `session_*` id or your user-supplied `externalId`. The server disambiguates via the `session_` prefix.
+
+```ts
+const session = await sessions.retrieve(chatId);
+console.log(session.currentRunId, session.tags, session.closedAt);
+```
+
+### `sessions.update(idOrExternalId, body, requestOptions?)`
+
+Mutate `tags` or `metadata` on an existing Session. `externalId` is read-only after create: it cannot be changed or cleared (it keys the session's durable streams and token scope), so sending a different value returns `422`.
+
+### `sessions.close(idOrExternalId, body?, requestOptions?)`
+
+Mark a Session as closed. Terminal and idempotent. The optional `reason` is stored on the row.
+
+```ts
+await sessions.close(chatId, { reason: "user signed out" });
+```
+
+### `sessions.list(options?, requestOptions?)`
+
+Cursor-paginated list of Sessions in the current environment. Returns a `CursorPagePromise` you can iterate with `for await`.
+
+```ts
+for await (const s of sessions.list({
+  type: "chat.agent",
+  tag: `user:${userId}`,
+  status: "ACTIVE",
+  limit: 50,
+})) {
+  console.log(s.id, s.externalId, s.createdAt);
+}
+```
+
+| Filter | Type | Notes |
+|---|---|---|
+| `type` | `string \| string[]` | e.g. `"chat.agent"` |
+| `tag` | `string \| string[]` | Matches `triggerConfig.tags` |
+| `taskIdentifier` | `string \| string[]` | Filter by task |
+| `externalId` | `string` | Exact match |
+| `status` | `"ACTIVE" \| "CLOSED" \| "EXPIRED"` | Lifecycle state |
+| `period` / `from` / `to` | window | Time-range filter |
+| `limit` / `after` / `before` | cursor | Pagination (1–100 per page; default 20) |
+
+### `sessions.open(idOrExternalId)`
+
+Open a lightweight `SessionHandle` to the realtime channels. Does **not** hit the network — each handle method calls the corresponding endpoint lazily.
+
+```ts
+const session = sessions.open(chatId);
+await session.out.append({ kind: "message", text: "hello" });
+const next = await session.in.once<MyEvent>({ timeoutMs: 30_000 });
+```
+
+## `SessionHandle`
+
+```ts
+class SessionHandle {
+  readonly id: string;
+  readonly in: SessionInputChannel;
+  readonly out: SessionOutputChannel;
+}
+```
+
+The two channels mirror the producer/consumer pair in `streams.define` (out) and `streams.input` (in), but are **session-scoped** rather than run-scoped — they survive across run boundaries.
+
+## `session.out` — task → clients
+
+The output channel. The task writes; external clients (browser, server action, another task) read via SSE. The underlying HTTP endpoints are documented in [Session channels](/management/sessions/channels) for non-SDK callers.
+
+### `out.append(value, options?)`
+
+Append a single record. Routes through `writer` internally so SSE consumers see the same parsed-object shape on every event.
+
+### `out.pipe(stream, options?)`
+
+Pipe an `AsyncIterable` or `ReadableStream` directly to S2 (the durable backing store). Returns `{ stream, waitUntilComplete }`.
+
+### `out.writer({ execute, ... })`
+
+Imperative writer. `execute({ write, merge })` runs against an in-memory queue whose records are piped to S2.
+
+```ts
+session.out.writer<MyChunk>({
+  execute: ({ write }) => {
+    write({ type: "text", text: "hi" });
+    write({ type: "text", text: " there" });
+  },
+});
+```
+
+### `out.read(options?)`
+
+Subscribe to SSE records on `.out`. Returns an async-iterable stream with auto-retry and `Last-Event-ID` resume.
+
+```ts
+const stream = await session.out.read<MyChunk>({
+  signal: AbortSignal.timeout(30_000),
+  lastEventId: lastSeenSeqNum,
+});
+for await (const chunk of stream) {
+  // ...
+}
+```
+
+### `out.writeControl(subtype, extraHeaders?)`
+
+Write a Trigger control record. Carries a `trigger-control` header valued with `subtype` (e.g. `turn-complete`, `upgrade-required`); the body is empty. The SDK transport filters control records out of the consumer-facing chunk stream — readers route them via `onControl` instead.
+
+Returns `{ lastEventId }` — useful for trim chains.
+
+### `out.trimTo(earliestSeqNum)`
+
+Append an S2 `trim` command. Records with `seq_num < earliestSeqNum` are eventually deleted. Idempotent and monotonic. `chat.agent` uses this to keep `session.out` bounded to roughly one turn at steady state.
+
+## `session.in` — clients → task
+
+The input channel. External clients call `send`; the task consumes via `on` / `once` / `peek` / `wait` / `waitWithIdleTimeout`. The underlying HTTP endpoints are documented in [Session channels](/management/sessions/channels) for non-SDK callers.
+
+### `in.send(value, requestOptions?)`
+
+Append a single record. Called from outside the task (browser, server action, another task).
+
+```ts
+const session = sessions.open(chatId);
+await session.in.send({ kind: "user-event", payload: { ... } });
+```
+
+### `in.on(handler)`
+
+Register a handler that fires for every record landing on `.in`. Buffered records flush on attach. Returns `{ off }`.
+
+### `in.once(options?)`
+
+Wait for the next record without suspending the run. `{ ok: true, output }` or `{ ok: false, error }` on timeout. Chain `.unwrap()` to get the data directly.
+
+```ts
+const result = await session.in.once<MyEvent>({ timeoutMs: 5_000 });
+if (result.ok) handle(result.output);
+```
+
+### `in.peek()`
+
+Non-blocking peek at the head of the `.in` buffer.
+
+### `in.wait(options?)`
+
+Suspend the current run until the next record arrives — frees compute while blocked. Only callable from inside `task.run()`.
+
+```ts
+const next = await session.in.wait<MyEvent>({ timeout: "1h" });
+```
+
+### `in.waitWithIdleTimeout({ idleTimeoutInSeconds, timeout, ... })`
+
+Hybrid: stay warm for `idleTimeoutInSeconds`, then suspend via `wait` if nothing arrives. `chat.agent`'s turn loop uses this to balance responsiveness and cost.
+
+```ts
+const next = await session.in.waitWithIdleTimeout<MyEvent>({
+  idleTimeoutInSeconds: 30,
+  timeout: "1h",
+  onSuspend: () => { /* persist before suspending */ },
+  onResume: () => { /* re-hydrate after resume */ },
+});
+```
+
+### `in.lastDispatchedSeqNum()`
+
+The highest S2 `seq_num` this channel has delivered to a consumer. Used by `chat.agent` to persist a resume cursor on each `turn-complete` so the next worker boot subscribes past already-processed records.
+
+## Authorization
+
+Browser and server-side clients use a session-scoped Public Access Token:
+
+```ts
+import { auth } from "@trigger.dev/sdk";
+
+const pat = await auth.createPublicToken({
+  scopes: {
+    read: { sessions: chatId },
+    write: { sessions: chatId },
+  },
+  expirationTime: "1h",
+});
+```
+
+Tokens authorize **both** URL forms: `/sessions/{externalId}/...` and `/sessions/session_*/...`.
+
+For the `chat.agent` transport, `auth.createPublicToken` is wrapped by `accessToken` in `useTriggerChatTransport`; for direct session access from your server, mint a token per request just like any other realtime resource.
+
+See [Session scopes](/management/authentication#session-scopes) for exactly what `read:sessions` and `write:sessions` grant, and why updating, closing, and appending to `.out` require a secret key.
+
+## See also
+
+- [Sessions HTTP API](/management/sessions/create) — The REST endpoints for creating, listing, retrieving, updating, and closing sessions, plus the [channel endpoints](/management/sessions/channels) for non-SDK callers.
+- [Session scopes](/management/authentication#session-scopes) — The public-token scopes that authorize session and channel access.
+- [How it works](/ai-chat/how-it-works) — How `chat.agent` builds on Sessions.
+- [Backend](/ai-chat/backend) — `chat.agent` / `chat.createSession` / raw `task()` with chat primitives.
+- [Client Protocol](/ai-chat/client-protocol) — The wire-level view of `.in/append` and `.out` SSE.
+- [Persistence and replay](/ai-chat/patterns/persistence-and-replay) — How tails are read at boot.