workflow 5.0.0-beta.5 → 5.0.0-beta.50

package/docs/api-reference/workflow/create-webhook.mdx

@@ -14,7 +14,7 @@ Creates a webhook that can be used to suspend and resume a workflow run upon rec
 Webhooks provide a way for external systems to send HTTP requests directly to your workflow. Unlike hooks which accept arbitrary payloads, webhooks work with standard HTTP `Request` objects and can return HTTP `Response` objects.
 
 <Callout type="warn">
-`createWebhook()` creates a public endpoint at `/.well-known/workflow/v1/webhook/:token`, and the token in that URL is the only authorization performed for incoming requests resuming that webhook. This is convenient for prototypes and simple resume links because it avoids creating another route, but if you need stronger security, prefer [`createHook()`](/docs/api-reference/workflow/create-hook) behind your own route and authorize the request before calling [`resumeHook()`](/docs/api-reference/workflow-api/resume-hook) to avoid unauthenticated workflow resumptions.
+`createWebhook()` creates a public endpoint at `/.well-known/workflow/v1/webhook/:token`, and the token in that URL is the only authorization performed for incoming requests resuming that webhook. This is convenient for prototypes and basic resume links because it avoids creating another route, but if you need stronger security, prefer [`createHook()`](/docs/api-reference/workflow/create-hook) behind your own route and authorize the request before calling [`resumeHook()`](/docs/api-reference/workflow-api/resume-hook) to avoid unauthenticated workflow resumptions.
 </Callout>
 
 ```ts lineNumbers
@@ -31,7 +31,7 @@ export async function webhookWorkflow() {
 }
 ```
 
-## API Signature
+## API signature
 
 ### Parameters
 
@@ -55,6 +55,7 @@ The returned `Webhook` object has:
 
 - `url`: The HTTP endpoint URL that external systems can call
 - `token`: The unique token identifying this webhook
+- `getConflict()`: A promise that resolves with the conflicting run if another active hook already owns this token, or `null` once the webhook endpoint has been registered
 - Implements `AsyncIterable<T>` for handling multiple requests, where `T` is `Request` (default) or `RequestWithResponse` (manual mode)
 
 When using `createWebhook({ respondWith: 'manual' })`, the resolved request type is `RequestWithResponse`, which extends the standard `Request` interface with a `respondWith(response: Response): Promise<void>` method for sending custom responses back to the caller.
@@ -62,22 +63,22 @@ When using `createWebhook({ respondWith: 'manual' })`, the resolved request type
 <Callout type="info">
 Use the simplest option that satisfies the prompt:
 
-- `createWebhook()` — generated callback URL, and the default `202 Accepted` response is fine
-- `createWebhook({ respondWith: 'manual' })` — generated callback URL, but you must send a custom body, status, or headers
-- `createHook()` + `resumeHook()` — the app resumes from server-side code with a deterministic business token instead of a generated callback URL
+- `createWebhook()`: generated callback URL, and the default `202 Accepted` response is fine
+- `createWebhook({ respondWith: 'manual' })`: generated callback URL, but you must send a custom body, status, or headers
+- `createHook()` + `resumeHook()`: the app resumes from server-side code with a deterministic business token instead of a generated callback URL
 </Callout>
 
 <details>
 <summary>Common wrong turns</summary>
 
-- Do not use `respondWith: 'manual'` just because the flow has a callback URL.
+- A callback URL alone does not require `respondWith: 'manual'`.
 - Do not use `RequestWithResponse` unless you chose manual mode.
 - Do not invent a custom callback route when `webhook.url` is the intended callback surface.
 </details>
 
 ## Examples
 
-### Basic Usage
+### Basic usage
 
 Create a webhook that receives HTTP requests and logs the request details:
 
@@ -100,11 +101,11 @@ export async function basicWebhookWorkflow() {
 }
 ```
 
-### Responding to Webhook Requests (Manual Mode)
+### Responding to webhook requests (manual mode)
 
 Use this section only when the caller requires a non-default HTTP response. If `202 Accepted` is acceptable, use `createWebhook()` without `respondWith: "manual"`.
 
-Pass `{ respondWith: "manual" }` to get a `RequestWithResponse` object with a `respondWith()` method. Note that `respondWith()` must be called from within a step function:
+Pass `{ respondWith: "manual" }` to get a `RequestWithResponse` object with a `respondWith()` method. Call `respondWith()` from within a step function:
 
 ```typescript lineNumbers
 import { createWebhook, type RequestWithResponse } from "workflow"
@@ -142,7 +143,7 @@ async function processData(data: any): Promise<void> {
 }
 ```
 
-### Waiting for Multiple Requests
+### Waiting for multiple requests
 
 You can also wait for multiple requests by using the `for await...of` syntax.
 
@@ -181,9 +182,9 @@ export async function eventCollectorWorkflow() {
 }
 ```
 
-## Related Functions
+## Related functions
 
-- [`createHook()`](/docs/api-reference/workflow/create-hook) — Use when the app resumes from server-side code with a deterministic business token.
-- [`resumeHook()`](/docs/api-reference/workflow-api/resume-hook) — Pairs with `createHook()` for deterministic server-side resume.
-- [`defineHook()`](/docs/api-reference/workflow/define-hook) — Type-safe hook helper.
-- [`resumeWebhook()`](/docs/api-reference/workflow-api/resume-webhook) — Low-level runtime API. Most integrations should call `webhook.url` directly instead of adding a custom callback route.
+- [`createHook()`](/docs/api-reference/workflow/create-hook): Use when the app resumes from server-side code with a deterministic business token.
+- [`resumeHook()`](/docs/api-reference/workflow-api/resume-hook): Pairs with `createHook()` for deterministic server-side resume.
+- [`defineHook()`](/docs/api-reference/workflow/define-hook): Type-safe hook helper.
+- [`resumeWebhook()`](/docs/api-reference/workflow-api/resume-webhook): Low-level runtime API. Most integrations should call `webhook.url` directly instead of adding a custom callback route.

package/docs/api-reference/workflow/define-hook.mdx

@@ -33,7 +33,7 @@ export async function nameWorkflow() {
 }
 ```
 
-## API Signature
+## API signature
 
 ### Parameters
 
@@ -46,27 +46,24 @@ showSections={['parameters']}
 
 ### Returns
 
+`defineHook()` returns a `TypedHook<TInput, TOutput>`:
+
 <TSDoc
 definition={`
-interface DefineHook<T> {
-  /**
-
-* Creates a new hook with the defined payload type.
-  */
-  create: (options?: HookOptions) => Hook<T>;
-
-  /**
-
-* Resumes a hook by sending a payload with the defined type.
-   */
-  resume: (token: string, payload: T) => Promise<HookEntity | null>;
+interface TypedHook<TInput, TOutput> {
+  /** Creates the hook. Call inside a "use workflow" function. */
+  create(options?: HookOptions): Hook<TOutput>;
+  /** Resumes the hook from runtime code. Resolves to the resumed hook; throws HookNotFoundError if the token does not match an active hook. */
+  resume(token: string, payload: TInput): Promise<HookEntity>;
 }
-export default DefineHook;`}
+export default TypedHook;`}
 />
 
+`create()` is called inside a `"use workflow"` function to create the hook; `resume()` is called from runtime code (an API route or server action). When a `schema` is provided, `resume()` accepts the raw input type (`TInput`) and the workflow receives the validated and possibly transformed output type (`TOutput`); without a schema, `TOutput` defaults to `TInput`. `resume()` throws [`HookNotFoundError`](/docs/api-reference/workflow-errors/hook-not-found-error) if the token does not match an active hook. It does not return `null`.
+
 ## Examples
 
-### Basic Type-Safe Hook Definition
+### Basic type-safe hook definition
 
 By defining the hook once with a specific payload type, you can reuse it in multiple workflows and API routes with automatic type safety.
 
@@ -91,30 +88,35 @@ export async function workflowWithApproval() {
 }
 ```
 
-### Resuming with Type Safety
+### Resuming with type safety
 
-Hooks can be resumed using the same defined hook and a token. By using the same hook, you can ensure that the payload matches the defined type when resuming a hook.
+Hooks can be resumed using the same defined hook and a token. By using the same hook, you can ensure that the payload matches the defined type when resuming a hook. `resume()` resolves to the resumed hook and throws [`HookNotFoundError`](/docs/api-reference/workflow-errors/hook-not-found-error) if the token does not match an active hook.
 
 ```typescript lineNumbers
+import { HookNotFoundError } from "workflow/errors";
+
 // Use the same defined hook to resume
 export async function POST(request: Request) {
   const { token, approved, comment } = await request.json();
 
-  // Type-safe resumption - TypeScript ensures the payload matches
-  const result = await approvalHook.resume(token, { // [!code highlight]
-    approved, // [!code highlight]
-    comment, // [!code highlight]
-  }); // [!code highlight]
-
-  if (!result) {
-    return Response.json({ error: "Hook not found" }, { status: 404 });
+  try {
+    // Type-safe resumption - TypeScript ensures the payload matches
+    const hook = await approvalHook.resume(token, { // [!code highlight]
+      approved, // [!code highlight]
+      comment, // [!code highlight]
+    }); // [!code highlight]
+
+    return Response.json({ success: true, runId: hook.runId });
+  } catch (error) {
+    if (HookNotFoundError.is(error)) { // [!code highlight]
+      return Response.json({ error: "Hook not found" }, { status: 404 });
+    }
+    throw error;
   }
-
-  return Response.json({ success: true, runId: result.runId });
 }
 ```
 
-### Validate and Transform with Schema
+### Validate and transform with schema
 
 You can provide runtime validation and transformation of hook payloads using the `schema` option. This option accepts any validator that conforms to the [Standard Schema v1](https://standardschema.dev) specification.
 
@@ -172,7 +174,7 @@ export async function POST(request: Request) {
 }
 ```
 
-#### Using Other Standard Schema Libraries
+#### Using other Standard Schema libraries
 
 The same pattern works with any Standard Schema v1 compliant library. Here's an example with [Valibot](https://valibot.dev):
 
@@ -188,7 +190,7 @@ export const approvalHook = defineHook({
 });
 ```
 
-### Customizing Tokens
+### Customizing tokens
 
 Tokens are used to identify a specific hook and for resuming a hook. You can customize the token to be more specific to a use case.
 
@@ -209,7 +211,7 @@ export async function slackBotWorkflow(channelId: string) {
 }
 ```
 
-## Related Functions
+## Related functions
 
-* [`createHook()`](/docs/api-reference/workflow/create-hook) - Create a hook in a workflow.
-* [`resumeHook()`](/docs/api-reference/workflow-api/resume-hook) - Resume a hook with a payload.
+- [`createHook()`](/docs/api-reference/workflow/create-hook): Create a hook in a workflow.
+- [`resumeHook()`](/docs/api-reference/workflow-api/resume-hook): Resume a hook with a payload.

package/docs/api-reference/workflow/fatal-error.mdx

@@ -27,18 +27,40 @@ async function fallibleStep() {
 }
 ```
 
-## API Signature
+## API signature
 
-### Parameters
+### Constructor
+
+`new FatalError(message)`
+
+| Parameter | Type     | Description        |
+| --------- | -------- | ------------------ |
+| `message` | `string` | The error message. |
+
+### Properties
 
 <TSDoc
 definition={`
-interface Error {
-  /**
-
-* The error message.
-   */
+interface FatalError {
+  /** The error message. */
   message: string;
+  /** Always true. Marks the error as non-retryable. */
+  fatal: boolean;
 }
-export default Error;`}
+export default FatalError;`}
 />
+
+### Static methods
+
+#### `FatalError.is(value)`
+
+Type-safe check for `FatalError` instances. Preferred over `instanceof` because it works across module boundaries and VM contexts.
+
+```typescript
+import { FatalError } from "workflow"
+declare const error: unknown; // @setup
+
+if (FatalError.is(error)) {
+  // error is typed as FatalError
+}
+```

package/docs/api-reference/workflow/fetch.mdx

@@ -7,12 +7,17 @@ prerequisites:
   - /docs/foundations/workflows-and-steps
 related:
   - /docs/errors/fetch-in-workflow
+  - /docs/foundations/idempotency
 ---
 
 Makes HTTP requests from within a workflow. This is a special step function that wraps the standard `fetch` API, automatically handling serialization and providing retry semantics.
 
 This is useful when you need to call external APIs or services from within your workflow.
 
+<Callout type="warn">
+Because workflow `fetch()` has retry semantics, use idempotency keys when the request mutates an external system, such as creating a charge, sending an email, or enqueueing work. See [Idempotency](/docs/foundations/idempotency).
+</Callout>
+
 <Callout>
 `fetch` is a *special* type of step function provided and should be called directly inside workflow functions.
 </Callout>
@@ -29,7 +34,7 @@ async function apiWorkflow() {
 }
 ```
 
-## API Signature
+## API signature
 
 ### Parameters
 
@@ -55,9 +60,9 @@ showSections={['returns']}
 
 ## Examples
 
-### Basic Usage
+### Basic usage
 
-Here's a simple example of how you can use `fetch` inside your workflow.
+Here's an example of how you can use `fetch` inside your workflow.
 
 ```typescript lineNumbers
 import { fetch } from "workflow"
@@ -82,13 +87,13 @@ async function apiWorkflow() {
 }
 ```
 
-We call `fetch()` with a URL and optional request options, just like the standard fetch API. The workflow runtime automatically handles the response serialization.
+We call `fetch()` with a URL and optional request options, like the standard fetch API. The workflow runtime automatically handles the response serialization.
 
-This API is provided as a convenience to easily use `fetch` in workflow, but often, you might want to extend and implement your own fetch for more powerful error handing and retry logic.
+This API lets you use `fetch` in a workflow. You can also implement a custom fetch for different error handling and retry logic.
 
-### Customizing Fetch Behavior
+### Customizing fetch behavior
 
-Here's an example of a custom fetch wrapper that provides more sophisticated error handling with custom retry logic:
+The following custom fetch wrapper provides more advanced error handling with custom retry logic. Call `globalThis.fetch` inside your own `"use step"` function because calling the workflow `fetch` imported from `workflow` would nest a step inside a step:
 
 ```typescript lineNumbers
 import { FatalError, RetryableError } from "workflow"
@@ -99,7 +104,7 @@ export async function customFetch(
 ) {
     "use step"
 
-    const response = await fetch(url, init)
+    const response = await globalThis.fetch(url, init)
 
     // Handle client errors (4xx) - don't retry
     if (response.status >= 400 && response.status < 500) {
@@ -140,7 +145,6 @@ export async function customFetch(
 
 This example demonstrates:
 
-- Setting custom `maxRetries` to 5 retries (6 total attempts including the initial attempt).
 - Throwing [`FatalError`](/docs/api-reference/workflow/fatal-error) for client errors (400-499) to prevent retries.
 - Handling 429 rate limiting by reading the `Retry-After` header and using [`RetryableError`](/docs/api-reference/workflow/retryable-error).
-- Allowing automatic retries for server errors (5xx).
+- Allowing automatic retries for server errors (5xx) by throwing a plain `Error`.

package/docs/api-reference/workflow/get-step-metadata.mdx

@@ -34,7 +34,7 @@ async function logStepId() {
 }
 ```
 
-### Example: Use `stepId` as an idempotency key
+### Example: use `stepId` as an idempotency key
 
 ```typescript lineNumbers
 import { getStepMetadata } from "workflow";
@@ -61,7 +61,7 @@ async function chargeUser(userId: string, amount: number) {
   <a href="/docs/foundations/idempotency">Idempotency</a> guide.
 </Callout>
 
-## API Signature
+## API signature
 
 ### Parameters
 

package/docs/api-reference/workflow/get-workflow-metadata.mdx

@@ -30,7 +30,7 @@ async function testWorkflow() {
 }
 ```
 
-### Detecting Workflow Runtime
+### Detecting workflow runtime
 
 You can use `getWorkflowMetadata` to detect whether your code is running inside a workflow context. This is useful when building shared utilities that need to behave differently inside and outside of workflows.
 
@@ -64,7 +64,7 @@ function log(message: string) {
 }
 ```
 
-### Detecting Encryption
+### Detecting encryption
 
 The `features` object indicates which capabilities are active for the current run. Library authors can use `features.encryption` to control whether sensitive data is included in step return values, which are serialized to the event log:
 
@@ -90,7 +90,7 @@ async function fetchUserProfile(userId: string) {
 }
 ```
 
-## API Signature
+## API signature
 
 ### Parameters
 

package/docs/api-reference/workflow/get-writable.mdx

@@ -47,7 +47,7 @@ async function writeToStream(writable: WritableStream) {
 }
 ```
 
-## API Signature
+## API signature
 
 ### Parameters
 
@@ -69,7 +69,7 @@ export default getWritable;`}
 
 Returns a `WritableStream<W>` where `W` is the type of data you plan to write to the stream.
 
-## Good to Know
+## Good to know
 
 - **Workflow functions can only obtain the stream** - Call `getWritable()` in a workflow to get the stream reference, but you cannot call methods like `getWriter()`, `write()`, or `close()` directly in the workflow context.
 - **Step functions can interact with streams** - Steps can receive the stream as an argument or call `getWritable()` directly, and they can freely interact with it (write, close, etc.).
@@ -81,9 +81,9 @@ Returns a `WritableStream<W>` where `W` is the type of data you plan to write to
 
 ## Examples
 
-### Basic Text Streaming
+### Basic text streaming
 
-Here's a simple example streaming text data:
+This example streams text data:
 
 ```typescript lineNumbers
 import { sleep, getWritable } from "workflow";
@@ -118,7 +118,7 @@ async function stepCloseOutputStream(writable: WritableStream) {
 }
 ```
 
-### Calling `getWritable()` Inside Steps
+### Calling `getWritable()` inside steps
 
 You can also call `getWritable()` directly inside step functions without passing it as a parameter:
 
@@ -157,7 +157,7 @@ async function stepCloseOutputStreamInside() {
 }
 ```
 
-### Using Namespaced Streams in Steps
+### Using namespaced streams in steps
 
 You can also use namespaced streams when calling `getWritable()` from steps:
 
@@ -201,7 +201,7 @@ async function closeStreams() {
 }
 ```
 
-### Advanced Chat Streaming
+### Advanced chat streaming
 
 Here's a more complex example showing how you might stream AI chat responses:
 

package/docs/api-reference/workflow/index.mdx

@@ -47,9 +47,12 @@ Workflow SDK contains the following functions you can use inside your workflow f
     <Card href="/docs/api-reference/workflow/get-writable" title="getWritable()">
         Access the current workflow run's default stream.
     </Card>
+    <Card href="/docs/api-reference/workflow/set-attributes" title="setAttributes()">
+        Attach string metadata to the current workflow run.
+    </Card>
 </Cards>
 
-## Error Classes
+## Error classes
 
 Workflow SDK includes error classes that can be thrown in a workflow or step to change the error exit strategy of a workflow.
 

package/docs/api-reference/workflow/retryable-error.mdx

@@ -31,7 +31,7 @@ async function retryStep() {
 The difference between `Error` and `RetryableError` may not be entirely obvious, since when both are thrown, they both retry. The difference is that `RetryableError` has an additional configurable `retryAfter` parameter.
 </Callout>
 
-## API Signature
+## API signature
 
 ### Parameters
 

package/docs/api-reference/workflow/set-attributes.mdx

@@ -0,0 +1,61 @@
+---
+title: setAttributes
+description: Attach string metadata to workflow run for observability.
+type: reference
+summary: Use setAttributes inside a workflow or step function to set run attributes.
+prerequisites:
+  - /docs/foundations/workflows-and-steps
+related:
+  - /docs/observability/attributes
+  - /docs/api-reference/workflow/fatal-error
+---
+
+Attaches string metadata to the current workflow run.
+
+```typescript lineNumbers
+import { setAttributes } from "workflow"
+
+export async function orderWorkflow(orderId: string) {
+  "use workflow"
+
+  await setAttributes({
+    phase: "received",
+    orderId,
+  })
+}
+```
+
+## API signature
+
+### Parameters
+
+<TSDoc
+definition={`
+import { setAttributes } from "workflow";
+export default setAttributes;`}
+showSections={['parameters']}
+/>
+
+## Usage
+
+Call `setAttributes` from a `"use workflow"` function or a `"use step"` function. Calling it from plain application code is not supported because there is no active workflow run.
+
+Attribute values must be strings. Pass `undefined` to remove an attribute:
+
+```typescript lineNumbers
+import { setAttributes } from "workflow"
+
+export async function cleanupAttributes() {
+  "use workflow"
+
+  await setAttributes({ staleKey: undefined })
+}
+```
+
+Attribute keys must be 1-256 characters, values must be strings up to 256 bytes, and each run can have up to 64 attributes. Keys that start with `$` are reserved for framework and library code.
+
+Validation errors throw [`FatalError`](/docs/api-reference/workflow/fatal-error) and fail the run before an attribute write is attempted.
+
+Calls from both workflow and step bodies append a native `attr_set` event, which the World materializes onto `run.attributes`. Workflow-originated events record a workflow writer; step-originated events record the originating step ID and attempt.
+
+Native attributes require spec version 4 or later. Step-body storage errors throw from `setAttributes`; catch them inside the step if the write should be best-effort. Workflow-body writes are committed when the workflow suspends: transient storage errors are retried with the suspension, while a write the World rejects as invalid (such as exceeding the per-run attribute cap across multiple calls) fails the run with the validation error.

package/docs/api-reference/workflow/sleep.mdx

@@ -14,7 +14,7 @@ Suspends a workflow for a specified duration or until an end date without consum
 This is useful when you want to resume a workflow after some duration or date.
 
 <Callout>
-`sleep` is a *special* type of step function and should be called directly inside workflow functions.
+`sleep` is a built-in workflow runtime function (backed by a timer event in the event log, not a step) and should be called directly inside workflow functions.
 </Callout>
 
 ```typescript lineNumbers
@@ -26,7 +26,7 @@ async function testWorkflow() {
 }
 ```
 
-## API Signature
+## API signature
 
 ### Parameters
 
@@ -39,7 +39,7 @@ showSections={['parameters']}
 
 ## Examples
 
-### Sleeping With a Duration
+### Sleeping with a duration
 
 You can specify a duration for `sleep` to suspend the workflow for a fixed amount of time.
 
@@ -52,7 +52,7 @@ async function testWorkflow() {
 }
 ```
 
-### Sleeping Until an End Date
+### Sleeping until an end date
 
 You can specify a future `Date` object for `sleep` to suspend the workflow until a specific date.