workflow 5.0.0-beta.9 → 5.0.1

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,12 +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/experimental-set-attributes" title="experimental_setAttributes()">
-        Attach experimental string metadata to the current workflow run.
+    <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,63 @@
+---
+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.
+
+Each call's complete `attr_set` event data must also fit in **8192 UTF-8 JSON bytes (8KiB)**. This includes the change keys and values, JSON escaping and structure, writer metadata (including the step ID and attempt for step calls), and the reserved-key option when enabled. It is not a limit on values alone. Split large updates into smaller calls; updates across multiple calls are not atomic and still share the 64-attribute per-run limit.
+
+Validation errors reject `setAttributes` with [`FatalError`](/docs/api-reference/workflow/fatal-error) before a new attribute write is attempted. Catch the error if the metadata is best-effort; an uncaught error fails the workflow or step. Previously persisted attribute events remain replayable.
+
+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.