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

package/docs/errors/timeout-in-workflow.mdx

@@ -9,21 +9,25 @@ related:
   - /docs/api-reference/workflow/sleep
 ---
 
+<CopyPrompt
+  text="Fix timer usage inside workflow functions. Search `&quot;use workflow&quot;` functions for `setTimeout`, `setInterval`, `timers/promises`, polling loops, or `AbortSignal.timeout()`. Replace workflow delays with `await sleep(&quot;5s&quot;)`, `await sleep(&quot;24h&quot;)`, or `await sleep(date)` from `workflow`. For polling, use a workflow loop that calls a `&quot;use step&quot;` helper to check external state and then `await sleep(...)` between attempts. If a step itself needs a short in-process delay, keep that timer inside the `&quot;use step&quot;` function only. Verify the workflow can replay and resume after the durable sleep."
+/>
+
 This error occurs when you try to use `setTimeout()`, `setInterval()`, or related timing functions directly inside a workflow function.
 
-## Error Message
+## Error message
 
-```
+```text
 Timeout functions like "setTimeout" and "setInterval" are not supported in workflow functions. Use the "sleep" function from "workflow" for time-based delays.
 ```
 
-## Why This Happens
+## Why this happens
 
 Workflow functions run in a sandboxed environment where timing functions like `setTimeout()` and `setInterval()` are not available. These functions rely on asynchronous scheduling that would break the **deterministic replay** guarantees that workflows depend on.
 
 When a workflow suspends and later resumes, it replays from the event log. If timing functions were allowed, the replay would produce different results than the original execution.
 
-## Quick Fix
+## Quick fix
 
 Use the `sleep` function from the `workflow` package for time-based delays. Unlike `setTimeout()`, `sleep` is tracked in the event log and replays correctly.
 
@@ -55,7 +59,7 @@ export async function delayedWorkflow() {
 }
 ```
 
-## Unavailable Functions
+## Unavailable functions
 
 These timing functions cannot be used in workflow functions:
 
@@ -66,9 +70,9 @@ These timing functions cannot be used in workflow functions:
 - `clearInterval()`
 - `clearImmediate()`
 
-## Common Scenarios
+## Common scenarios
 
-### Polling with Delays
+### Polling with delays
 
 If you need to poll an external service with delays between requests:
 
@@ -98,7 +102,7 @@ async function checkStatus() {
 }
 ```
 
-### Scheduled Delays
+### Scheduled delays
 
 For workflows that need to wait for a specific duration:
 

package/docs/errors/webhook-invalid-respond-with-value.mdx

@@ -11,13 +11,13 @@ related:
 
 This error occurs when you provide an invalid value for the `respondWith` option when creating a webhook. The `respondWith` option must be either `"manual"` or a `Response` object.
 
-## Error Message
+## Error message
 
-```
+```text
 Invalid `respondWith` value: [value]
 ```
 
-## Why This Happens
+## Why this happens
 
 When creating a webhook with `createWebhook()`, you can specify how the webhook should respond to incoming HTTP requests using the `respondWith` option. This option only accepts specific values:
 
@@ -25,16 +25,16 @@ When creating a webhook with `createWebhook()`, you can specify how the webhook
 2. A `Response` object - A pre-defined response to send immediately
 3. `undefined` (default) - Returns a `202 Accepted` response
 
-## Common Causes
+## Common causes
 
-### Using an Invalid String Value
+### Using an invalid string value
 
 ```typescript lineNumbers
 // Error - invalid string value
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "automatic", // Error! // [!code highlight]
   });
 }
@@ -49,7 +49,7 @@ import { createWebhook } from "workflow";
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual", // [!code highlight]
   });
 
@@ -60,14 +60,14 @@ export async function webhookWorkflow() {
 }
 ```
 
-### Using a Non-Response Object
+### Using a non-Response object
 
 ```typescript lineNumbers
 // Error - plain object instead of Response
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: { status: 200, body: "OK" }, // Error! // [!code highlight]
   });
 }
@@ -82,32 +82,32 @@ import { createWebhook } from "workflow";
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: new Response("OK", { status: 200 }), // [!code highlight]
   });
 }
 ```
 
-## Valid Usage Examples
+## Valid usage examples
 
-### Default Behavior (202 Response)
+### Default behavior (202 response)
 
 ```typescript lineNumbers
 import { createWebhook } from "workflow";
 
 // Returns 202 Accepted automatically
-const webhook = await createWebhook();
+const webhook = createWebhook();
 const request = await webhook;
 // No need to send a response
 ```
 
-### Manual Response
+### Manual response
 
 ```typescript lineNumbers
 import { createWebhook } from "workflow";
 
 // Manual response control
-const webhook = await createWebhook({
+const webhook = createWebhook({
   respondWith: "manual",
 });
 
@@ -125,13 +125,13 @@ await request.respondWith(
 );
 ```
 
-### Pre-defined Response
+### Pre-defined response
 
 ```typescript lineNumbers
 import { createWebhook } from "workflow";
 
 // Immediate response
-const webhook = await createWebhook({
+const webhook = createWebhook({
   respondWith: new Response("Request received", { status: 200 }),
 });
 
@@ -139,7 +139,7 @@ const request = await webhook;
 // Response already sent
 ```
 
-## Learn More
+## Learn more
 
 - [createWebhook() API Reference](/docs/api-reference/workflow/create-webhook)
 - [resumeWebhook() API Reference](/docs/api-reference/workflow-api/resume-webhook)

package/docs/errors/webhook-response-not-sent.mdx

@@ -9,30 +9,34 @@ related:
   - /docs/api-reference/workflow/create-webhook
 ---
 
+<CopyPrompt
+  text="Fix webhook-response-not-sent errors. Find `createWebhook({ respondWith: &quot;manual&quot; })` usage. In the workflow, await the webhook request and pass the `RequestWithResponse` into a `&quot;use step&quot;` helper for validation and side effects. In every success, validation failure, catch, and early-return branch, call `await request.respondWith(new Response(...))` or `await request.respondWith(Response.json(...))` exactly once before the webhook completes. If manual control is not needed, remove `respondWith: &quot;manual&quot;` or use a static `Response` option. Add tests or local webhook calls for success, invalid input, and thrown-error paths."
+/>
+
 This error occurs when a webhook is configured with `respondWith: "manual"` but the workflow does not send a response using `request.respondWith()` before the webhook execution completes.
 
-## Error Message
+## Error message
 
-```
+```text
 Workflow run did not send a response
 ```
 
-## Why This Happens
+## Why this happens
 
 When you create a webhook with `respondWith: "manual"`, you are responsible for calling `request.respondWith()` to send the HTTP response back to the caller. If the workflow execution completes without sending a response, this error will be thrown.
 
 The webhook infrastructure waits for a response to be sent, and if none is provided, it cannot complete the HTTP request properly.
 
-## Common Causes
+## Common causes
 
-### Forgetting to Call `request.respondWith()`
+### Forgetting to call `request.respondWith()`
 
 ```typescript lineNumbers
 // Error - no response sent
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual",
   });
 
@@ -55,7 +59,7 @@ import { createWebhook } from "workflow";
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual",
   });
 
@@ -70,14 +74,14 @@ export async function webhookWorkflow() {
 }
 ```
 
-### Conditional Response Logic
+### Conditional response logic
 
 ```typescript lineNumbers
 // Error - response only sent in some branches
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual",
   });
 
@@ -100,7 +104,7 @@ import { createWebhook } from "workflow";
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual",
   });
 
@@ -115,14 +119,14 @@ export async function webhookWorkflow() {
 }
 ```
 
-### Exception Before Response
+### Exception before response
 
 ```typescript lineNumbers
 // Error - exception thrown before response
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual",
   });
 
@@ -145,7 +149,7 @@ import { createWebhook } from "workflow";
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook({
+  const webhook = createWebhook({
     respondWith: "manual",
   });
 
@@ -164,7 +168,7 @@ export async function webhookWorkflow() {
 }
 ```
 
-## Alternative: Use Default Response Mode
+## Alternative: Use default response mode
 
 If you don't need custom response control, consider using the default response mode which automatically returns a `202 Accepted` response:
 
@@ -175,7 +179,7 @@ import { createWebhook } from "workflow";
 export async function webhookWorkflow() {
   "use workflow";
 
-  const webhook = await createWebhook(); // [!code highlight]
+  const webhook = createWebhook(); // [!code highlight]
   const request = await webhook;
 
   // Process request asynchronously
@@ -185,7 +189,7 @@ export async function webhookWorkflow() {
 }
 ```
 
-## Learn More
+## Learn more
 
 - [createWebhook() API Reference](/docs/api-reference/workflow/create-webhook)
 - [resumeWebhook() API Reference](/docs/api-reference/workflow-api/resume-webhook)

package/docs/errors/workflow-not-registered.mdx

@@ -12,19 +12,19 @@ related:
 
 This error occurs when the Workflow runtime tries to execute a workflow function that is not registered in the current deployment. When this happens, the run fails with a `RUNTIME_ERROR` error code.
 
-## Error Message
+## Error message
 
-```
+```text
 Workflow "<workflowName>" is not registered in the current deployment.
 This usually means a run was started against a deployment that does not
 have this workflow, or there was a build/bundling issue.
 ```
 
-## Why This Happens
+## Why this happens
 
 This error means the deployment that received the workflow execution request does not have the specified workflow function in its bundle. This is an **infrastructure error**, not a user code error.
 
-## Common Causes
+## Common causes
 
 ### Run started against a deployment without the workflow
 
@@ -57,7 +57,7 @@ Something went wrong during the build process that caused the workflow function
 - The workflow function is not exported from the workflow file
 - An esbuild or SWC plugin error silently excluded the workflow
 
-## How to Resolve
+## How to resolve
 
 1. **If the workflow was renamed or moved:** Deploy with the workflow restored to its original name and location, then retry the run. Alternatively, start a new run using the updated workflow name against the current deployment.
 

package/docs/foundations/cancellation.mdx

@@ -6,7 +6,6 @@ summary: Cancel in-flight work with AbortSignal or stop entire workflow runs.
 prerequisites:
   - /docs/foundations/workflows-and-steps
 related:
-  - /docs/foundations/common-patterns
   - /docs/foundations/hooks
   - /docs/how-it-works/cancellation
 ---
@@ -15,7 +14,7 @@ Workflow DevKit supports two cancellation mechanisms: **AbortSignal** for fine-g
 
 ## AbortSignal
 
-`AbortController` and `AbortSignal` work across workflow and step boundaries. Create an `AbortController` with `new AbortController()` in a workflow function, pass its signal to steps, and call `abort()` — using the standard [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) API you already know.
+`AbortController` and `AbortSignal` work across workflow and step boundaries. Create an `AbortController` with `new AbortController()` in a workflow function, pass its signal to steps, and call `abort()` using the standard [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) API.
 
 ```typescript lineNumbers
 import { sleep } from "workflow";
@@ -49,17 +48,17 @@ async function longRunningStep(signal: AbortSignal) {
 }
 ```
 
-No special imports, no wrapper functions — just the standard `AbortController` API.
+Use the standard `AbortController` API without special imports or wrapper functions.
 
 <Callout type="info">
-Cancellation is **cooperative**. Aborting a signal doesn't forcefully kill a step — it's up to the step's code to check `signal.aborted` or pass the signal to APIs like `fetch` that respect it. If a step ignores the signal, it runs to completion.
+Cancellation is **cooperative**. Aborting a signal doesn't forcefully kill a step. The step's code must check `signal.aborted` or pass the signal to APIs like `fetch` that respect it. If a step ignores the signal, it runs to completion.
 </Callout>
 
 <Callout type="info">
 To learn how `AbortController` works durably across workflow suspensions, replays, and step boundaries, see [How Cancellation Works](/docs/how-it-works/cancellation).
 </Callout>
 
-### Timeout with Cancellation
+### Timeout with cancellation
 
 Race a step against a timeout, and cancel the step if the timeout wins:
 
@@ -91,7 +90,7 @@ async function fetchUrl(url: string, signal: AbortSignal) {
 }
 ```
 
-### Cancelling Parallel Work
+### Cancelling parallel work
 
 When racing multiple steps, cancel the losers:
 
@@ -117,7 +116,7 @@ async function fetchUrl(url: string, signal: AbortSignal) {
 }
 ```
 
-### Passing Signal Through a Pipeline
+### Passing signal through a pipeline
 
 Pass the same signal to a chain of steps. Aborting cancels whichever step is currently running:
 
@@ -176,7 +175,7 @@ async function uploadData(data: ArrayBuffer, signal: AbortSignal) {
 }
 ```
 
-### Step-Initiated Abort
+### Step-initiated abort
 
 A step can receive the full `AbortController` and call `abort()` to cancel parallel work. This is useful for watchdog/monitor patterns where one step observes an external condition and cancels other in-flight steps:
 
@@ -221,7 +220,7 @@ async function monitorQuota(userId: string, controller: AbortController) {
 }
 ```
 
-### User-Triggered Cancellation with Hooks
+### User-triggered cancellation with hooks
 
 Combine hooks with abort controllers to let users cancel in-flight work from an external API:
 
@@ -267,23 +266,23 @@ export async function POST(request: Request) {
 }
 ```
 
-### How Steps Handle Abort
+### How steps handle abort
 
 When an `AbortSignal` is aborted, the behavior depends on how the step uses it:
 
-| Usage | Behavior on Abort |
+| Usage | Behavior on abort |
 |-------|-------------------|
-| `fetch(url, { signal })` | Request is cancelled, throws `AbortError` |
+| `fetch(url, { signal })` | Request is canceled, throws `AbortError` |
 | `signal.throwIfAborted()` | Throws the abort reason |
 | `signal.aborted` check | Returns `true`, step can exit gracefully |
 | `signal.addEventListener('abort', fn)` | Callback fires, step can clean up |
 | Ignored | Step runs to completion (abort is cooperative) |
 
-### Abort Errors Skip Retries
+### Abort errors skip retries
 
-When a step throws due to an abort (e.g., `fetch` throws `AbortError`, or `signal.throwIfAborted()` throws), the error is automatically wrapped in a `FatalError`. This means the step **skips retries** and the error bubbles up to the workflow immediately.
+When a step throws due to an abort (for example, `fetch` throws `AbortError`, or `signal.throwIfAborted()` throws), the runtime wraps the error in a `FatalError`. The step **skips retries**, and the error immediately bubbles up to the workflow.
 
-This is the correct behavior because an abort is an intentional cancellation — retrying the step would just result in another abort. You don't need to manually wrap abort errors in `FatalError`.
+An abort is an intentional cancellation, so retrying the step would result in another abort. You don't need to manually wrap abort errors in `FatalError`.
 
 ```typescript lineNumbers
 import { sleep } from "workflow";
@@ -300,7 +299,7 @@ export async function workflow() {
     if (result === null) controller.abort();
     return result;
   } catch (err) {
-    // AbortError arrives as FatalError — no retries attempted // [!code highlight]
+    // AbortError arrives as FatalError, with no retries attempted // [!code highlight]
     return { status: "cancelled" };
   }
 }
@@ -313,7 +312,7 @@ async function cancellableStep(signal: AbortSignal) {
 }
 ```
 
-### Passing AbortSignal as Workflow Input
+### Passing AbortSignal as workflow input
 
 You can pass an `AbortSignal` from external code into a workflow via `start()`:
 
@@ -330,15 +329,15 @@ export async function POST(request: Request) {
 }
 ```
 
-When the signal is serialized at the `start()` boundary, an event listener is attached to the external signal that writes the cancellation packet to the backing stream. This means the external `abort()` propagates into the workflow — but only while the originating process is still alive (same constraint as passing a `ReadableStream` as input).
+When the signal is serialized at the `start()` boundary, an event listener attaches to the external signal and writes the cancellation packet to the backing stream. The external `abort()` propagates into the workflow only while the originating process is still alive (the same constraint as passing a `ReadableStream` as input).
 
 <Callout type="info">
 For reliable external cancellation that works regardless of process lifetime, prefer the [User-Triggered Cancellation with Hooks](#user-triggered-cancellation-with-hooks) pattern. Hooks are durable and don't depend on the caller's process staying alive.
 </Callout>
 
-## Run Cancellation
+## Run cancellation
 
-Run cancellation stops an entire workflow at the next suspension point. Unlike `AbortSignal`, it is not cooperative — the workflow does not continue executing after cancellation.
+Run cancellation stops an entire workflow at the next suspension point. Unlike `AbortSignal`, it is not cooperative. The workflow does not continue executing after cancellation.
 
 ```typescript title="app/api/cancel-run/route.ts" lineNumbers
 import { getRun } from "workflow/api";
@@ -354,10 +353,10 @@ export async function POST(request: Request) {
 ```
 
 <Callout type="info">
-Calling `run.cancel()` is the same action as clicking the **Cancel** button on a run in the observability UI — both produce identical `run_cancelled` events in the event log.
+Calling `run.cancel()` is the same action as clicking the **Cancel** button on a run in the observability UI. Both produce identical `run_cancelled` events in the event log.
 </Callout>
 
-When a run is cancelled:
+When a run is canceled:
 - The workflow stops at its next suspension point (step call, hook await, or sleep)
 - A `run_cancelled` event is recorded in the [event log](/docs/how-it-works/event-sourcing)
 - All associated hooks are disposed and their tokens released
@@ -367,19 +366,19 @@ When a run is cancelled:
 Run cancellation does **not** automatically abort any outstanding `AbortSignal`s. Steps that are currently executing will run to completion. If you need in-flight cancellation of specific operations, use `AbortSignal`.
 </Callout>
 
-## AbortSignal vs. Run Cancellation
+## AbortSignal vs. run cancellation
 
 | | AbortSignal | Run Cancellation |
 |---|---|---|
 | **Scope** | Individual operations within a step | Entire workflow run |
 | **Triggered by** | Your code (`controller.abort()`) | External API (`run.cancel()`) |
-| **Cooperative** | Yes — steps must check the signal | No — workflow stops at the next suspension point |
+| **Cooperative** | Yes. Steps must check the signal | No. The workflow stops at the next suspension point |
 | **Granularity** | Can target specific steps or operations | All-or-nothing |
 | **In-flight steps** | Aborted immediately if using the signal | Run to completion |
 
 Use `AbortSignal` when you need fine-grained, in-flight cancellation of specific operations. Use run cancellation when you want to stop the entire workflow.
 
-## Best Practices
+## Best practices
 
 **Use `throwIfAborted()` before expensive work.** This throws the signal's abort reason if the signal is already aborted, preventing wasted compute:
 
@@ -449,12 +448,12 @@ export async function workflow() {
 }
 ```
 
-This is safe even if both steps have already completed — aborting a finished operation is a no-op.
+This is safe even if both steps have already completed because aborting a finished operation is a no-op.
 
-## Related Documentation
+## Related documentation
 
-- [How Cancellation Works](/docs/how-it-works/cancellation) — Hook and stream backing, serialization internals
-- [Serialization](/docs/foundations/serialization) — Understanding serializable types
-- [Common Patterns](/docs/foundations/common-patterns) — Timeout and race patterns
-- [Hooks](/docs/foundations/hooks) — Pausing workflows for external events
-- [Errors and Retries](/docs/foundations/errors-and-retries) — Handling step failures
+- [How Cancellation Works](/docs/how-it-works/cancellation): Hook and stream backing, serialization internals
+- [Serialization](/docs/foundations/serialization): Understanding serializable types
+- [Cookbook](/cookbook): Timeout, race, and other reliability patterns
+- [Hooks](/docs/foundations/hooks): Pausing workflows for external events
+- [Errors and Retries](/docs/foundations/errors-and-retries): Handling step failures

package/docs/foundations/errors-and-retries.mdx

@@ -1,6 +1,6 @@
 ---
 title: Errors & Retrying
-description: Customize retry behavior with FatalError and RetryableError for robust error handling.
+description: Customize retry behavior with FatalError and RetryableError.
 type: conceptual
 summary: Control how steps handle failures and customize retry behavior.
 prerequisites:
@@ -12,7 +12,7 @@ related:
 
 By default, errors thrown inside steps are retried. Additionally, Workflow SDK provides two new types of errors you can use to customize retries.
 
-## Default Retrying
+## Default retrying
 
 By default, steps retry up to 3 times on arbitrary errors. You can customize the number of retries by adding a `maxRetries` property to the step function.
 
@@ -42,9 +42,9 @@ Steps get enqueued immediately after a failure. Read on to see how this can be c
   more information.
 </Callout>
 
-## Intentional Errors
+## Intentional errors
 
-When your step needs to intentionally throw an error and skip retrying, simply throw a [`FatalError`](/docs/api-reference/workflow/fatal-error).
+When your step needs to intentionally throw an error and skip retrying, throw a [`FatalError`](/docs/api-reference/workflow/fatal-error).
 
 ```typescript lineNumbers
 import { FatalError } from "workflow";
@@ -67,7 +67,7 @@ async function callApi(endpoint: string) {
 }
 ```
 
-## Customize Retry Behavior
+## Customize retry behavior
 
 When you need to customize the delay on a retry, use [`RetryableError`](/docs/api-reference/workflow/retryable-error) and set the `retryAfter` property.
 
@@ -97,7 +97,7 @@ async function callApi(endpoint: string) {
 }
 ```
 
-## Advanced Example
+## Advanced example
 
 This final example combines everything we've learned, along with [`getStepMetadata`](/docs/api-reference/workflow/get-step-metadata).
 
@@ -139,7 +139,32 @@ callApi.maxRetries = 5; // Retry up to 5 times on failure (6 total attempts)
   step can run up to 4 times total (1 initial attempt + 3 retries).
 </Callout>
 
-## Error Codes
+## Serialization failures
+
+A step whose arguments or return value cannot be [serialized](/docs/foundations/serialization) fails like a step whose body threw a `FatalError`: the failure is deterministic, so it skips the retry loop, and a `try/catch` around the step call observes the `SerializationError`:
+
+```typescript lineNumbers
+async function someStep(input: unknown) {
+  "use step";
+  return input;
+}
+
+export async function myWorkflow(input: unknown) {
+  "use workflow";
+
+  try {
+    await someStep(input);
+  } catch (err) {
+    if ((err as Error).name === "SerializationError") {
+      // e.g. `Failed to serialize step arguments at path "..."`
+    }
+  }
+}
+```
+
+Uncaught, the run fails immediately with the `USER_ERROR` code, without retrying. See [serialization-failed](/docs/errors/serialization-failed) for common causes and fixes.
+
+## Error codes
 
 When a workflow run fails, the error includes an `errorCode` that classifies the failure, alongside the original thrown value (preserved as `cause`):
 
@@ -153,7 +178,7 @@ try {
   const result = await run.returnValue;
 } catch (err) {
   if (WorkflowRunFailedError.is(err)) {
-    console.log(err.errorCode); // "USER_ERROR", "RUNTIME_ERROR", or undefined
+    console.log(err.errorCode); // e.g. "USER_ERROR", "MAX_EVENTS_EXCEEDED", or undefined
     // `cause` is the original thrown value, hydrated through the workflow
     // serialization pipeline. It can be any thrown value, so check shape.
     if (err.cause instanceof Error) {
@@ -166,13 +191,19 @@ try {
 | Code | Meaning |
 | --- | --- |
 | `USER_ERROR` | An error thrown in your workflow or step code (including propagated step failures like `FatalError`) |
-| `RUNTIME_ERROR` | An internal runtime error such as a corrupted event log or missing data. If you see this, please [file an issue](https://github.com/vercel/workflow/issues) |
+| `MAX_EVENTS_EXCEEDED` | The run reached the World's per-run event ceiling (25,000 on the Local and Vercel Worlds). Split unbounded loops into [child workflows](/cookbook/advanced/child-workflows); see [Limits](/docs/configuration/runtime-tuning#limits) |
+| `MAX_DELIVERIES_EXCEEDED` | The run exceeded the maximum number of queue deliveries |
+| `REPLAY_TIMEOUT` | A workflow replay exceeded the maximum allowed duration |
+| `REPLAY_DIVERGENCE` | A replay could not consume the event log deterministically, usually because of non-deterministic workflow code. |
+| `CORRUPTED_EVENT_LOG` | The event log cannot be replayed: it contains orphaned or mismatched events, or one of its stored payloads is no longer readable from the World's storage. If you see this, please [file an issue](https://github.com/vercel/workflow/issues) |
+| `WORLD_CONTRACT_ERROR` | A World response violated the SDK contract; points at a World implementation bug |
+| `RUNTIME_ERROR` | An internal runtime error. If you see this, please [file an issue](https://github.com/vercel/workflow/issues) |
 
 <Callout type="info">
-  The error code is also available on the run entity via the CLI (`npx workflow inspect runs <runId>`) in the `error.code` field, and as an OTEL span attribute (`workflow.error.code`) for observability.
+  The error code is also available on the run entity through the Workflow CLI (`npx workflow inspect runs <runId>`) in the `error.code` field, and as an OpenTelemetry span attribute (`workflow.error.code`) for observability.
 </Callout>
 
-## Rolling Back Failed Steps
+## Rolling back failed steps
 
 When a workflow fails partway through, it can leave the system in an inconsistent state.
 A common pattern to address this is "rollbacks": for each successful step, record a corresponding rollback action that can undo it.