workflow 4.1.0-beta.56 → 4.1.0-beta.58

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,73 @@
1
+ ---
2
+ title: corrupted-event-log
3
+ description: The workflow's event log contains an event that no consumer can process, indicating corruption or invalid state.
4
+ type: troubleshooting
5
+ summary: Resolve corrupted event log errors caused by duplicate or orphaned events.
6
+ prerequisites:
7
+ - /docs/foundations/workflows-and-steps
8
+ related:
9
+ - /docs/foundations/errors-and-retries
10
+ ---
11
+
12
+ This error occurs when the Workflow runtime encounters an event in the event log that no registered consumer can process. This means the event log is in an invalid state — typically due to duplicate or orphaned events.
13
+
14
+ This is a **workflow-level fatal error**. It cannot be caught or handled inside your workflow code. A corrupted event log immediately fails the entire run without executing any more user code. The run must be retried from outside the workflow.
15
+
16
+ ## Error Message
17
+
18
+ ```
19
+ Unconsumed event in event log: eventType=<type>, correlationId=<id>, eventId=<id>. This indicates a corrupted or invalid event log.
20
+ ```
21
+
22
+ ## Why This Happens
23
+
24
+ Workflows persist their progress as an ordered event log. During replay, the runtime processes each event in sequence — every event must be consumed by a matching callback (e.g., a step or sleep waiting for its result). When an event has no matching consumer, the runtime cannot advance past it, which would block all subsequent events and hang the workflow indefinitely.
25
+
26
+ Instead of silently hanging, the runtime raises a `WorkflowRuntimeError` to fail the workflow fast and surface the problem.
27
+
28
+ Common scenarios that produce this error:
29
+
30
+ 1. **Duplicate completion events** — Two `wait_completed` events for a single `wait_created`, or two `step_completed` events for the same step. The first is consumed normally, but the second has no consumer.
31
+ 2. **Orphaned events** — A `step_completed` or `wait_completed` event whose `correlationId` doesn't match any step or sleep in the workflow code.
32
+ 3. **Events after terminal state** — An event that arrives after its corresponding step or wait has already reached a terminal state (e.g., `step_retrying` after `step_completed`).
33
+
34
+ ## What To Do
35
+
36
+ This error indicates a bug in the Workflow SDK or Workflow server — not in your workflow code. Your workflow code does not need to change. Follow these steps to resolve the issue:
37
+
38
+ ### 1. Upgrade to the latest `workflow` package
39
+
40
+ The bug that caused the corrupted event log may have already been identified and fixed in a newer version. Update to the latest version:
41
+
42
+ ```bash
43
+ npm install workflow@latest
44
+ ```
45
+
46
+ ### 2. Retry the failed run
47
+
48
+ Since this is a fatal error, the run is automatically marked as `failed`. You can re-run it using the **Re-run** button in the Workflow Dashboard.
49
+
50
+ ### 3. Report the issue
51
+
52
+ If the error persists after upgrading, please [open an issue on GitHub](https://github.com/vercel/workflow/issues/new) so we can investigate and fix the underlying bug. Include the following details to help us diagnose the problem:
53
+
54
+ - The version of the `workflow` package you are using
55
+ - The run ID(s) of the affected workflow run(s)
56
+ - The error message (including `eventType`, `correlationId`, and `eventId`)
57
+ - Any details about the event log or the workflow that triggered the error
58
+
59
+ ## This Error Cannot Be Caught
60
+
61
+ Unlike other workflow errors, a corrupted event log error is **not catchable** inside your workflow function. Because the event log itself is invalid, the runtime cannot safely continue executing any user code. The entire run fails immediately and is marked as `failed`.
62
+
63
+ To handle this programmatically from outside the workflow, you can check the run status:
64
+
65
+ ```typescript lineNumbers
66
+ import { getRun } from "workflow/api";
67
+
68
+ const run = getRun("wrun_abc123");
69
+ const status = await run.status;
70
+ if (status === "failed") {
71
+ console.error("Run failed");
72
+ }
73
+ ```
@@ -34,6 +34,9 @@ Fix common mistakes when creating and executing workflows in the **Workflow DevK
34
34
  <Card href="/docs/errors/webhook-response-not-sent" title="webhook-response-not-sent">
35
35
  Learn how to send responses when using manual webhook response mode.
36
36
  </Card>
37
+ <Card href="/docs/errors/corrupted-event-log" title="corrupted-event-log">
38
+ Learn how to handle corrupted or invalid event logs.
39
+ </Card>
37
40
  </Cards>
38
41
 
39
42
  ## Learn More
@@ -33,7 +33,7 @@ In the Workflow DevKit, the following entity types are managed through events:
33
33
  - **Runs**: Workflow execution instances (materialized in storage)
34
34
  - **Steps**: Individual atomic operations within a workflow (materialized in storage)
35
35
  - **Hooks**: Suspension points that can receive external data (materialized in storage)
36
- - **Waits**: Sleep or delay operations (tracked via events only, not materialized)
36
+ - **Waits**: Sleep or delay operations (materialized in storage)
37
37
 
38
38
  ## Entity Lifecycles
39
39
 
@@ -151,7 +151,7 @@ flowchart TD
151
151
  - `completed`: Delay period has elapsed, workflow can resume
152
152
 
153
153
  <Callout type="info">
154
- Unlike Runs, Steps, and Hooks, waits are conceptual entities tracked only through events. There is no separate "Wait" record in storage that can be queried—the wait state is derived entirely from the `wait_created` and `wait_completed` events in the event log.
154
+ Like Runs, Steps, and Hooks, waits are materialized as entities in storage. When a `wait_created` event is processed, a wait entity is created with status `waiting`. When a `wait_completed` event is processed, the wait entity is atomically transitioned to `completed` this guarantees that a wait can only be completed exactly once, even if multiple concurrent invocations attempt to complete it simultaneously.
155
155
  </Callout>
156
156
 
157
157
  ## Event Types Reference
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "workflow",
3
- "version": "4.1.0-beta.56",
3
+ "version": "4.1.0-beta.58",
4
4
  "description": "Workflow DevKit - Build durable, resilient, and observable workflows",
5
5
  "main": "dist/typescript-plugin.cjs",
6
6
  "type": "module",
@@ -38,7 +38,6 @@
38
38
  "default": "./dist/api.js"
39
39
  },
40
40
  "./internal/errors": "./dist/internal/errors.js",
41
- "./internal/serialization": "./dist/internal/serialization.js",
42
41
  "./internal/builtins": "./dist/internal/builtins.js",
43
42
  "./internal/private": "./dist/internal/private.js",
44
43
  "./internal/class-serialization": "./dist/internal/class-serialization.js",
@@ -53,17 +52,17 @@
53
52
  },
54
53
  "dependencies": {
55
54
  "ms": "2.1.3",
56
- "@workflow/astro": "4.0.0-beta.30",
57
- "@workflow/cli": "4.1.0-beta.56",
58
- "@workflow/core": "4.1.0-beta.56",
59
- "@workflow/errors": "4.1.0-beta.15",
55
+ "@workflow/astro": "4.0.0-beta.32",
56
+ "@workflow/cli": "4.1.0-beta.58",
57
+ "@workflow/core": "4.1.0-beta.58",
58
+ "@workflow/errors": "4.1.0-beta.16",
60
59
  "@workflow/typescript-plugin": "4.0.1-beta.4",
61
- "@workflow/next": "4.0.1-beta.52",
62
- "@workflow/nest": "0.0.0-beta.5",
63
- "@workflow/nitro": "4.0.1-beta.51",
64
- "@workflow/nuxt": "4.0.1-beta.40",
65
- "@workflow/sveltekit": "4.0.0-beta.45",
66
- "@workflow/rollup": "4.0.0-beta.13"
60
+ "@workflow/next": "4.0.1-beta.54",
61
+ "@workflow/nest": "0.0.0-beta.7",
62
+ "@workflow/nitro": "4.0.1-beta.53",
63
+ "@workflow/nuxt": "4.0.1-beta.42",
64
+ "@workflow/sveltekit": "4.0.0-beta.47",
65
+ "@workflow/rollup": "4.0.0-beta.15"
67
66
  },
68
67
  "devDependencies": {
69
68
  "@types/ms": "2.1.0",
@@ -1,2 +0,0 @@
1
- export * from '@workflow/core/serialization';
2
- //# sourceMappingURL=serialization.d.ts.map
@@ -1 +0,0 @@
1
- {"version":3,"file":"serialization.d.ts","sourceRoot":"","sources":["../../src/internal/serialization.ts"],"names":[],"mappings":"AAAA,cAAc,8BAA8B,CAAC"}
@@ -1,2 +0,0 @@
1
- export * from '@workflow/core/serialization';
2
- //# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoic2VyaWFsaXphdGlvbi5qcyIsInNvdXJjZVJvb3QiOiIiLCJzb3VyY2VzIjpbIi4uLy4uL3NyYy9pbnRlcm5hbC9zZXJpYWxpemF0aW9uLnRzIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiJBQUFBLGNBQWMsOEJBQThCLENBQUMifQ==