You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2a3b11b
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/content/docs/v4/errors/corrupted-event-log.mdx
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,21 +9,21 @@ related:
9
9
- /docs/foundations/errors-and-retries
10
10
---
11
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.
12
+
This error occurs when the Workflow runtime repeatedly cannot replay events in the event log. This usually means the event log is in an invalid state, such as duplicate or orphaned events, or that a runtime determinism bug persists across retry attempts.
13
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.
14
+
This is a **workflow-level fatal error**. It cannot be caught or handled inside your workflow code. The runtime first retries transient replay divergence automatically; it marks the run as failed with this error only after replay still cannot recover.
15
15
16
16
## Error Message
17
17
18
18
```
19
-
Unconsumed event in event log: eventType=<type>, correlationId=<id>, eventId=<id>. This indicates a corrupted or invalid event log.
19
+
Workflow replay diverged <divergenceCount> times after <maxRecoveryReplays> recovery replays; latest divergent event was <eventId>. Last divergence: <details>
20
20
```
21
21
22
22
## Why This Happens
23
23
24
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
25
26
-
Instead of silently hanging, the runtime raises a `WorkflowRuntimeError` to fail the workflow fast and surface the problem.
26
+
Instead of silently hanging, the runtime retries a divergent replay before failing the workflow and surfacing this terminal error.
27
27
28
28
Common scenarios that produce this error:
29
29
@@ -45,7 +45,7 @@ npm install workflow@latest
45
45
46
46
### 2. Retry the failed run
47
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.
48
+
If this error is displayed, automatic replay recovery has already been exhausted and the run has been marked as `failed`. You can re-run it using the **Re-run** button in the Workflow Dashboard.
description: A workflow replay temporarily followed a path that did not match its recorded events.
4
+
type: troubleshooting
5
+
summary: Understand automatic recovery when a workflow replay diverges from its event history.
6
+
prerequisites:
7
+
- /docs/foundations/workflows-and-steps
8
+
related:
9
+
- /docs/errors/corrupted-event-log
10
+
- /docs/foundations/errors-and-retries
11
+
---
12
+
13
+
A replay divergence occurs when one invocation of a workflow cannot consume the durable event history using the promises, hooks, sleeps, or steps it created during replay.
14
+
15
+
This is an SDK/runtime signal, not an error thrown by your workflow code. It is not catchable inside a workflow function.
16
+
17
+
## Automatic Recovery
18
+
19
+
A single divergent replay does not prove that persisted history is corrupted. For example, asynchronous delivery ordering may cause one invocation to follow the wrong side of a race while another replay can follow the recorded history correctly.
20
+
21
+
The runtime automatically queues another replay when an invocation reports `REPLAY_DIVERGENCE`. No terminal `run_failed` event is written during these recovery attempts.
22
+
23
+
If recovery replays continue to diverge after the retry budget is exhausted, the runtime marks the run as failed with `CORRUPTED_EVENT_LOG` and records the latest divergent event for diagnosis.
24
+
25
+
## What To Do
26
+
27
+
Most replay divergence signals recover without action. If a run ultimately fails with `CORRUPTED_EVENT_LOG`, update to the latest `workflow` package and report the run ID and error details if the failure persists.
Copy file name to clipboardExpand all lines: docs/content/docs/v5/errors/corrupted-event-log.mdx
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,21 +9,21 @@ related:
9
9
- /docs/foundations/errors-and-retries
10
10
---
11
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.
12
+
This error occurs when the Workflow runtime repeatedly cannot replay events in the event log. This usually means the event log is in an invalid state, such as duplicate or orphaned events, or that a runtime determinism bug persists across retry attempts.
13
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.
14
+
This is a **workflow-level fatal error**. It cannot be caught or handled inside your workflow code. The runtime first retries transient replay divergence automatically; it marks the run as failed with this error only after replay still cannot recover.
15
15
16
16
## Error Message
17
17
18
18
```
19
-
Unconsumed event in event log: eventType=<type>, correlationId=<id>, eventId=<id>. This indicates a corrupted or invalid event log.
19
+
Workflow replay diverged <divergenceCount> times after <maxRecoveryReplays> recovery replays; latest divergent event was <eventId>. Last divergence: <details>
20
20
```
21
21
22
22
## Why This Happens
23
23
24
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
25
26
-
Instead of silently hanging, the runtime raises a `WorkflowRuntimeError` to fail the workflow fast and surface the problem.
26
+
Instead of silently hanging, the runtime retries a divergent replay before failing the workflow and surfacing this terminal error.
27
27
28
28
Common scenarios that produce this error:
29
29
@@ -45,7 +45,7 @@ npm install workflow@latest
45
45
46
46
### 2. Retry the failed run
47
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.
48
+
If this error is displayed, automatic replay recovery has already been exhausted and the run has been marked as `failed`. You can re-run it using the **Re-run** button in the Workflow Dashboard.
description: A workflow replay temporarily followed a path that did not match its recorded events.
4
+
type: troubleshooting
5
+
summary: Understand automatic recovery when a workflow replay diverges from its event history.
6
+
prerequisites:
7
+
- /docs/foundations/workflows-and-steps
8
+
related:
9
+
- /docs/errors/corrupted-event-log
10
+
- /docs/foundations/errors-and-retries
11
+
---
12
+
13
+
A replay divergence occurs when one invocation of a workflow cannot consume the durable event history using the promises, hooks, sleeps, or steps it created during replay.
14
+
15
+
This is an SDK/runtime signal, not an error thrown by your workflow code. It is not catchable inside a workflow function.
16
+
17
+
## Automatic Recovery
18
+
19
+
A single divergent replay does not prove that persisted history is corrupted. For example, asynchronous delivery ordering may cause one invocation to follow the wrong side of a race while another replay can follow the recorded history correctly.
20
+
21
+
The runtime automatically queues another replay when an invocation reports `REPLAY_DIVERGENCE`. No terminal `run_failed` event is written during these recovery attempts.
22
+
23
+
If recovery replays continue to diverge after the retry budget is exhausted, the runtime marks the run as failed with `CORRUPTED_EVENT_LOG` and records the latest divergent event for diagnosis.
24
+
25
+
## What To Do
26
+
27
+
Most replay divergence signals recover without action. If a run ultimately fails with `CORRUPTED_EVENT_LOG`, update to the latest `workflow` package and report the run ID and error details if the failure persists.
0 commit comments