workflow 5.0.0-beta.44 → 5.0.0-beta.47

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

@@ -12,9 +12,11 @@ related:
 
 Resumes a workflow run by sending a payload to a hook identified by its token.
 
-It creates a `hook_received` event and re-triggers the workflow to continue execution.
+It durably writes the `hook_received` event and only then publishes a workflow wake. The call resolves only after both operations succeed, in that order.
 
-A Hook kept by `experimental_minRetention` after its workflow ends cannot be resumed. `resumeHook()` throws `HookNotFoundError` in that case.
+`resumeHook()` throws `HookNotFoundError` when no hook holds the token or when its `hook_received` write is refused because the hook was disposed or the run ended. See [durable hook resume](/docs/changelog/lazy-hook-resume).
+
+If `resumeHook()` throws any other error, the outcome is ambiguous only in dispatch, never in durability: the event may already be durable even though the workflow wake failed, and any later wake of the run delivers it. Calling `resumeHook()` again creates a new `resumeId` and can append a second `hook_received`. Callers that need at-most-once behavior across separate invocations must retain and deduplicate their own request key.
 
 <Callout type="warn">
 `resumeHook` is a runtime function that must be called from outside a workflow function.
@@ -50,7 +52,7 @@ showSections={["parameters"]}
 
 ### Returns
 
-Returns a `Promise<ResumedHook>`, a `Hook` extended with an optional `resilientResume` flag. Resolving means the resume was accepted and the workflow will continue, whether the `hook_received` event was written directly or, on the parallel fast path, delivered through the workflow queue for the runtime to materialize (see the [lazy hook resume changelog](/docs/changelog/resilient-resume)). `resilientResume` is `true` only when the direct event write failed transiently and the resume was recovered through the queue; on the happy path it is absent. The resolved hook:
+Returns a `Promise<ResumedHook>`, a `Hook` extended with an optional `resilientResume` flag. Resolving means the payload is durably recorded as `hook_received` and the workflow wake was accepted. `resilientResume` is retained for source compatibility and is no longer set by any path. The resolved hook:
 
 <TSDoc
 definition={`

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

@@ -11,7 +11,7 @@ related:
 
 Resumes a workflow run by sending an HTTP `Request` to a webhook identified by its token.
 
-This function creates a `hook_received` event and re-triggers the workflow to continue execution. It's designed to be called from API routes or server actions that receive external HTTP requests.
+This function publishes a workflow invocation carrying the request; the runtime creates the `hook_received` event from it and continues execution. It's designed to be called from API routes or server actions that receive external HTTP requests.
 
 <Callout type="warn">
 `resumeWebhook` is a runtime function that must be called from outside a workflow function.

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

@@ -108,6 +108,18 @@ The `deploymentId` option is currently a Vercel-specific feature. Other Worlds m
 In Worlds without atomic, immutable deployments (such as local development or self-hosted Postgres), there is no notion of multiple deployments to resolve between, so `deploymentId: "latest"` has no effect: the SDK logs a warning and the run targets the current deployment. This means a workflow that opts into `"latest"` on Vercel still runs unchanged in local development.
 </Callout>
 
+<Callout type="info">
+Resolving `"latest"` is the one `start()` path that calls the Vercel API, so it
+needs an identity that can see the calling deployment. Inside a Vercel
+deployment the SDK authenticates with the deployment's own OIDC token, which
+carries the owning team, and this takes precedence over a `VERCEL_TOKEN` set in
+the function's environment. A `VERCEL_TOKEN` belongs to a *user* and carries no
+team, so authenticating with it scopes the lookup to that user's default team
+and fails with a 404 whenever that is not the team that owns the deployment.
+Outside a deployment (CLI, CI, the dashboard) `VERCEL_TOKEN` is still used;
+configure the World's `teamId` so the request is scoped explicitly.
+</Callout>
+
 <Callout type="warn">
 When using `deploymentId: "latest"`, the workflow run will execute on a potentially different deployment than the one calling `start()`. Be mindful of forward and backward compatibility:
 

package/docs/changelog/attributes-mvp.mdx

@@ -273,7 +273,7 @@ If you need behavior the MVP does not provide (read, list, filter, initial attri
 Unit tests in `@workflow/world` (validation surface) and `@workflow/core` (VM-side dispatch + host-side stub):
 
 - Validation rules: key length, value byte cap, `$` prefix, per-batch duplicates, post-merge count cap (with `existingKeys` so updates of present keys don't falsely trip the cap)
-- Reserved `$` namespace: rejected by default, accepted when `allowReservedAttributes: true` is passed (both for `validateAttributeKey` and at the batch level via `validateAttributeChanges`)
+- Reserved `$` namespace: rejected by default and accepted by the contextual `validateAttributeChanges` check when `allowReservedAttributes: true` is passed
 - `experimental_setAttributes({})` is a no-op (no dispatch, no events)
 - `undefined` value normalizes to a `null`-valued change on the wire
 - The `{ allowReservedAttributes: true }` opt-in is forwarded through the step bridge so the world receives the flag
@@ -367,7 +367,7 @@ For the MVP the endpoint reuses the existing `WORKFLOW_EVENT` fact with `eventTy
 
 ### Validation rules are shared between SDK and world
 
-Validation lives in a single helper exported from `@workflow/world` (`validateAttributeChanges`, `validateAttributeKey`, `validateAttributeValue`). Both the SDK `experimental_setAttributes` helper and the `world-local` / `world-postgres` implementations call it; the `world-vercel` backing service applies the same rules independently. The shared module is the authoritative spec for the limits (256-char keys, 256-byte values, max 64 attributes per run, `$`-prefixed keys reserved), so any future change goes through one file.
+Context-free validation lives in the exported Zod schemas (`AttributeKeySchema`, `AttributeValueSchema`, `AttributeChangeSchema`, and `AttributeChangesSchema`). The schema-free `validateAttributeChanges` helper adds rules that depend on caller context, including the post-merge count and reserved `$` namespace. Both the SDK `experimental_setAttributes` helper and the `world-local` / `world-postgres` implementations call it; the `world-vercel` backing service applies the same rules independently. The shared module remains the authoritative spec for the limits (256-char keys, 256-byte values, max 64 attributes per run, `$`-prefixed keys reserved).
 
 ### Run row reconstruction had to thread `attributes` through
 

package/docs/changelog/index.mdx

@@ -12,6 +12,7 @@ Stay up to date with the latest changes to Workflow SDK.
 
 ## 2026
 
+- [Durable hook resume](/docs/changelog/lazy-hook-resume) (August 2026)
 - [Resilient hook resume](/docs/changelog/resilient-resume) (July 2026)
 - [Eager processing of steps and incremental event replay](/docs/changelog/eager-processing) (March 2026)
 - Serializable AbortController and AbortSignal (March 12, 2026)

package/docs/changelog/lazy-hook-resume.mdx

@@ -0,0 +1,78 @@
+---
+title: Durable hook resume
+description: resumeHook() durably writes hook_received and only then publishes the workflow wake, so a resolved call can never be lost to a disposal race.
+---
+
+# Durable hook resume
+
+## Motivation
+
+The previous lazy path published the serialized hook payload on the workflow
+queue and left the queue consumer to create `hook_received`. If the hook was
+disposed after `resumeHook()` returned but before the consumer write committed,
+that write was rejected and the acknowledged queue delivery could not resume the
+workflow: the caller was told the resume succeeded, and it was lost.
+
+`resumeHook()` now resolves only after both the durable event write and the
+workflow wake have succeeded, in that order.
+
+## Design
+
+The dispatch is strictly serial:
+
+1. The hook is resolved by token. An unknown token throws `HookNotFoundError`.
+2. The producer writes `hook_received` durably into the run's event log. A
+   client-minted `resumeId` and payload digest ride the write when the backend
+   supports atomic resume claims, so transport-level retries of the same write
+   converge on exactly one committed event. A write refused because the hook
+   was disposed or the run ended throws `HookNotFoundError`.
+3. Only after the write is acknowledged does the producer publish the workflow
+   wake. The wake carries no payload — the payload lives in the event log — so
+   nothing rides on the queue message but the trigger. Publication is retried
+   a bounded number of times.
+
+Because the event is committed before the wake exists, a disposal or run
+completion racing the queue delivery cannot erase a resume the caller was told
+succeeded: the delivery replays the committed event from the log.
+
+- `ResumedHook.resilientResume` remains on the type for source compatibility
+  and is no longer set. The internal `resumeHookDurable()` entry point is
+  removed; `resumeHook()` itself now provides the durable guarantee.
+
+A resolved call proves that the event is durable and the wake was accepted.
+`HookNotFoundError` proves this invocation committed no event. Any other thrown
+error is ambiguous only in *dispatch*, never in durability: a wake failure
+after the write leaves the event committed, and any later wake of the run
+(from any source) delivers it. A fresh `resumeHook()` invocation mints a new
+`resumeId`, so blindly retrying a failed call can append a second
+`hook_received`; callers that need at-most-once behavior across separate
+invocations must deduplicate on their own request key.
+
+## Behavior change: resumes against an ended run
+
+The lazy path never observed the server's rejection — it published a message
+and resolved, so a resume against a run that had already ended reported
+success (reachable whenever the hook record outlives its run, e.g. token
+retention). The durable write restores the check: **a resume against an ended
+run now throws `HookNotFoundError`**, and a late webhook delivery to a
+finished run answers 404 where it previously answered 202. Senders that treat
+4xx as terminal will stop retrying such deliveries; that is the correct
+signal, since nothing can resume an ended run.
+
+A transient write conflict (HTTP 409, e.g. an event-slot conflict that
+escaped the server's internal retry budget under contention) is no longer
+re-keyed to `HookNotFoundError`. It surfaces as a retryable error, and its
+rejected transaction committed nothing, so retrying the resume is safe.
+
+## Compatibility
+
+Nothing about the queue message changes: the wake has the same shape the
+sequential path always published, so no consumer, backend, or server
+coordination is needed and either side can roll back independently.
+
+Consumers continue to accept legacy `hookInput` messages from older producers,
+materializing their payload before replay. This permits rolling upgrades
+without a coordinated producer and consumer deployment.
+
+`WORKFLOW_DISABLE_LAZY_HOOK_RESUME` no longer gates anything and is ignored:
+there is no lazy path left to disable.

package/docs/changelog/meta.json

@@ -2,6 +2,7 @@
   "title": "Changelog",
   "pages": [
     "index",
+    "lazy-hook-resume",
     "eager-processing",
     "resilient-resume",
     "resilient-start",

package/docs/changelog/resilient-resume.mdx

@@ -5,6 +5,16 @@ description: resumeHook() now tolerates transient event storage failures when th
 
 # Resilient `resumeHook()`
 
+<Callout type="info">
+  Superseded by [durable hook resume](/docs/changelog/lazy-hook-resume):
+  `resumeHook()` now writes the `hook_received` event durably and only then
+  publishes the workflow wake, so the two-writer design, the queue-carried
+  payload, and the `resilientResume` flag described below are historical. The
+  `(runId, resumeId)` constraint remains, converging transport-level retries
+  of the producer's own write (and legacy `hookInput` redeliveries from older
+  producers).
+</Callout>
+
 ## Motivation
 
 `resumeHook()` used to write the `hook_received` event and dispatch the workflow queue message strictly one after the other, so every resume paid two sequential round trips and a transient event-storage failure failed the whole resume even when the queue was healthy. This change runs both writes **concurrently** (cutting a round trip off resume latency) and, on the same path, brings `resumeHook()` to parity with [resilient `start()`](/docs/changelog/resilient-start): a transient event-write failure no longer fails the resume when the payload can still be delivered through the queue.
@@ -19,4 +29,4 @@ description: resumeHook() now tolerates transient event storage failures when th
 
 ## Compatibility
 
-The parallel fast path is gated per resume: it activates only when both the target run's queue consumer and the live backend independently attest dedup support (re-checked on every resume, so rollout and rollback both degrade safely). Otherwise (for oversized payloads, legacy runs, or with `WORKFLOW_DISABLE_LAZY_HOOK_RESUME=1`), `resumeHook()` falls back to the original sequential write-then-dispatch path. Because runs keep executing on the deployment they were created on, a resume targeting a run from an older deployment uses the sequential path.
+The parallel fast path is gated per resume: it activates only when both the target run's queue consumer and the live backend independently attest dedup support (re-checked on every resume, so rollout and rollback both degrade safely). Otherwise (for oversized payloads or legacy runs), `resumeHook()` falls back to the original sequential write-then-dispatch path. Because runs keep executing on the deployment they were created on, a resume targeting a run from an older deployment uses the sequential path.

package/docs/configuration/runtime-tuning.mdx

@@ -81,13 +81,6 @@ For example, a workflow can run a 10-minute inline step even with `WORKFLOW_REPL
 - Default: `3`
 - Recovery replays before replay divergence is recorded as corruption.
 
-### `WORKFLOW_DISABLE_LAZY_HOOK_RESUME`
-
-- Default: enabled (lazy hook resume on)
-- Resuming a hook persists the `hook_received` event and publishes the workflow invocation concurrently, cutting a round trip off resume latency. On this parallel path, the queue message also carries the payload, so a transient event-write failure still resumes the run. The queue consumer re-ensures the `hook_received` event before replay. A backend `(runId, resumeId)` constraint keeps the two writers converging on exactly one event.
-- The runtime falls back to the sequential path when the consumer or backend does not attest dedup support (or the payload is too large to inline on the queue message). On the sequential path, the event is written *before* dispatch, and its failure fails the resume. The fallback trades away that resilience to stay safe when dedup is not enforced; it does not preserve it.
-- Set `1` to force the sequential path as a kill switch. The chosen strategy is reported on the resume span as `workflow.hook.resume_strategy`.
-
 ### `WORKFLOW_DEPLOYMENT_MISMATCH_MAX_RETRIES`
 
 - Default: `3`
@@ -99,7 +92,7 @@ For example, a workflow can run a 10-minute inline step even with `WORKFLOW_REPL
 ### `WORKFLOW_RESILIENT_STEP_DISPATCH`
 
 - Default: disabled
-- When a suspension hands newly created steps to the queue, the runtime publishes each step's execution message in parallel with its `step_created` event write instead of sequencing them, cutting a round trip per dispatched step. The message also carries the serialized step input (`stepInput`), so a transient `step_created` write failure (429 / 5xx / transport) still executes the step. The queue consumer idempotently re-ensures the event before running it, converging with the producer's write on the step's correlation ID. This mirrors resilient start (`runInput`) and the lazy hook resume (`hookInput`).
+- When a suspension hands newly created steps to the queue, the runtime publishes each step's execution message in parallel with its `step_created` event write instead of sequencing them, cutting a round trip per dispatched step. The message also carries the serialized step input (`stepInput`), so a transient `step_created` write failure (429 / 5xx / transport) still executes the step. The queue consumer idempotently re-ensures the event before running it, converging with the producer's write on the step's correlation ID. This mirrors resilient start (`runInput`) and the legacy lazy hook resume's `hookInput` (which current producers no longer send; see [durable hook resume](/docs/changelog/lazy-hook-resume)).
 - It is off by default because the publish races the create's verdict, and a create can come back refused: as a duplicate this replay should stop pursuing, or as a [stale write](#stale-reads-and-why-nothing-has-to-be-rejected) on a World that refuses rather than reports. Either way the message carrying the payload is already out, so the consumer can materialize a step whose create was refused, and nothing orders the verdict before the consumer's redelivery re-ensure. The sequential path is the only one that gives the message a happens-after edge over it.
 - Even when enabled, the runtime falls back to the sequential create-then-publish dispatch when the step input is too large to inline on the queue message, or when the run's queue transport cannot carry binary payloads (pre-CBOR spec versions).
 - Producer-side recoveries are reported on the suspension span as `workflow.step.resilient_dispatch_recovered`; a consumer that materialized the event reports `workflow.step.resilient_dispatch_materialized`.
@@ -193,7 +186,7 @@ For example, a workflow can run a 10-minute inline step even with `WORKFLOW_REPL
 
 - Default: enabled
 - Keeps the suspended workflow VM alive across inline steps within one invocation, so each iteration of the inline loop appends only the newly written events instead of replaying the whole event log in a fresh VM.
-- Suspensions involving hooks, waits, or attributes, as well as any replay divergence, always fall back to a full replay.
+- A step-driven suspension can keep the VM retained even when hooks are open or created at the same boundary. Hook-only suspensions park the invocation. Suspensions involving waits or attributes, runs with an open wait, and any replay divergence fall back to a full replay.
 - Step inputs made of plain data (objects, arrays, primitives) and standard built-ins (`Map`, `Set`, `Date`, `RegExp`, typed arrays, `ArrayBuffer`, `URL`, `Headers`) keep the VM retained. Patching or polyfilling built-in prototypes doesn't change that because serialization never calls them. A boundary falls back to a full replay only when serializing its arguments runs code the workflow controls, such as a getter, a proxy, or a custom class serializer, or computes an `Error`'s stack trace.
 - Set `0` or `false` to replay from scratch in a fresh VM on every iteration.
 

package/docs/errors/corrupted-event-log.mdx

@@ -1,37 +1,46 @@
 ---
 title: corrupted-event-log
-description: The workflow's event log contains an event that no consumer can process, indicating corruption or invalid state.
+description: The workflow's event log contains an event that cannot be processed or a stored payload that cannot be read.
 type: troubleshooting
-summary: Resolve corrupted event log errors caused by orphaned or unattributable events.
+summary: Resolve corrupted event log errors caused by invalid events or unreadable stored payloads.
 prerequisites:
   - /docs/foundations/workflows-and-steps
 related:
   - /docs/foundations/errors-and-retries
 ---
 
-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 an orphaned event or one no consumer can attribute to anything the workflow did, or that a runtime determinism bug persists across retry attempts.
+This error occurs when the Workflow runtime cannot safely replay the event log. The log may be in an invalid state, such as an orphaned event or one no consumer can attribute to anything the workflow did, or it may reference a stored payload that the World can no longer read.
 
-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.
+This is a **workflow-level fatal error**. It cannot be caught or handled inside your workflow code. The runtime retries transient replay divergence automatically, but an unreadable stored payload is terminal immediately because replaying cannot restore it.
 
 ## Error message
 
+For replay divergence:
+
 ```text
 Workflow replay diverged <divergenceCount> times after <maxRecoveryReplays> recovery replays; latest divergent event was <eventId>. Last divergence: <details>
 ```
 
+For an unreadable stored payload:
+
+```text
+the event log references a payload that no longer exists in storage: <details>
+```
+
 ## Why this happens
 
 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, such as a step or sleep waiting for its result. An event no callback ever claims is one the runtime would have to drop to finish the run, so it fails the run instead of returning a result that silently ignored it.
 
 A delivery written from outside the replay, such as a hook firing or a step completing on another invocation, can land ahead of the events the replay is writing itself. That is ordinary concurrency rather than corruption, so the runtime holds such an event and offers it to each consumer the replay registers afterwards. The failure comes only when the workflow function returns while an event is still held, at which point no consumer can ever appear. A replay that suspends still holding one reports it on the span (`workflow.events.parked.count`, `.event_id`, `.event_type`) and leaves the decision to the replay that follows.
 
-Before failing, the runtime retries a divergent replay and surfaces this terminal error only if replay still cannot recover.
+Before failing on divergence, the runtime retries the replay and surfaces this terminal error only if replay still cannot recover. It does not retry a payload that the World reports as permanently missing.
 
 Common scenarios that produce this error:
 
 - **An unclaimed event that repeats nothing**: A duplicate of a kind the log already records for that entity is read past rather than failing the run, so a second `step_completed` or `wait_completed` is not this error (see [Duplicate Events](/docs/how-it-works/event-sourcing#duplicate-events)). What fails is an unclaimed event with no earlier counterpart to defer to: a `step_started` behind a `step_completed` on a log that never recorded a `step_started`, for instance. No consumer remains for the step, and there is no earlier event of that kind the replay could be reading instead.
 - **Orphaned events**: A `step_completed` or `wait_completed` event whose `correlationId` doesn't match any step or sleep in the workflow code, so the replay reaches its end still holding it.
 - **A hole in the log**: Events are numbered by their position in the run's log, and those positions are dense, so a position below the log's highest that holds no event means the log the replay loaded is incomplete. The runtime cannot tell a position no write ever occupied from one whose event it failed to read, so it refuses to replay rather than produce a result that may be silently wrong. See [`WORKFLOW_SLOT_GAP_CHECK`](/docs/configuration/runtime-tuning#workflow_slot_gap_check).
+- **An unreadable stored payload**: An event row still references a payload object, but the World reports that the object no longer exists in its storage. The same log would fail on every replay, so the run fails immediately instead of retrying forever.
 
 ## What to do
 
@@ -47,7 +56,7 @@ npm install workflow@latest
 
 ### 2. Retry the failed run
 
-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.
+If this error reports replay divergence, automatic replay recovery has already been exhausted. If it reports an unreadable payload, recovery cannot recreate that payload. In either case, the run has been marked as `failed`. You can re-run the workflow using the **Re-run** button in the Workflow Dashboard; a re-run starts a new run with a new event log.
 
 ### 3. Report the issue
 
@@ -55,7 +64,7 @@ If the error persists after upgrading, [open an issue on GitHub](https://github.
 
 - The version of the `workflow` package you are using
 - The run ID(s) of the affected workflow run(s)
-- The error message (including `eventType`, `correlationId`, and `eventId`)
+- The complete error message, including any `eventType`, `correlationId`, `eventId`, or payload details
 - Any details about the event log or the workflow that triggered the error
 
 ## This error cannot be caught

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

@@ -195,7 +195,7 @@ try {
 | `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 contains orphaned or mismatched events and cannot be replayed. If you see this, please [file an issue](https://github.com/vercel/workflow/issues) |
+| `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) |
 

package/docs/whats-new.mdx

@@ -33,7 +33,7 @@ The largest change in v5 has no API surface: the runtime does far less work per
 
 **The runtime avoids waiting on the persistence layer where it can determine that is safe for your workload.** The runtime skips many API calls when they aren't needed, such as requesting the event log on a run's first invocation. Step creation is folded into step execution rather than being its own round trip. The inline loop consumes the event-log delta from the previous step's write instead of re-listing events. Each optimization is gated on specific runtime conditions and can be turned off individually. See [Runtime tuning](/docs/configuration/runtime-tuning).
 
-**The workflow VM is kept alive across inline steps.** Within one invocation, a step-only suspension keeps the live VM and hydrated state, so the next iteration appends only the newly written events instead of rebuilding the sandbox and replaying the whole log. Step inputs made of plain data or standard built-ins keep this fast path; see [`WORKFLOW_RETAINED_VM`](/docs/configuration/runtime-tuning#workflow_retained_vm).
+**The workflow VM is kept alive across inline steps.** Within one invocation, a step-driven suspension keeps the live VM and hydrated state, including when hooks are open or created at the same boundary, so the next iteration appends only the newly written events instead of rebuilding the sandbox and replaying the whole log. Step inputs made of plain data or standard built-ins keep this fast path; see [`WORKFLOW_RETAINED_VM`](/docs/configuration/runtime-tuning#workflow_retained_vm).
 
 **Resuming a hook takes one round trip instead of two.** `resumeHook()` writes the `hook_received` event and dispatches the queue message concurrently, with a `(runId, resumeId)` dedup constraint keeping the two writers converging on exactly one event. See [Resilient hook resumption](/docs/changelog/resilient-resume).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "workflow",
-  "version": "5.0.0-beta.44",
+  "version": "5.0.0-beta.47",
   "description": "Workflow SDK - Build durable, resilient, and observable workflows",
   "main": "dist/typescript-plugin.cjs",
   "type": "module",
@@ -59,18 +59,18 @@
   },
   "dependencies": {
     "ms": "2.1.3",
-    "@workflow/astro": "5.0.0-beta.44",
-    "@workflow/cli": "5.0.0-beta.44",
-    "@workflow/core": "5.0.0-beta.44",
-    "@workflow/errors": "5.0.0-beta.18",
+    "@workflow/astro": "5.0.0-beta.47",
+    "@workflow/cli": "5.0.0-beta.47",
+    "@workflow/core": "5.0.0-beta.47",
+    "@workflow/errors": "5.0.0-beta.19",
     "@workflow/typescript-plugin": "5.0.0-beta.5",
-    "@workflow/utils": "5.0.0-beta.9",
-    "@workflow/next": "5.0.0-beta.44",
-    "@workflow/nest": "5.0.0-beta.44",
-    "@workflow/nitro": "5.0.0-beta.44",
-    "@workflow/nuxt": "5.0.0-beta.44",
-    "@workflow/sveltekit": "5.0.0-beta.44",
-    "@workflow/rollup": "5.0.0-beta.44"
+    "@workflow/utils": "5.0.0-beta.10",
+    "@workflow/next": "5.0.0-beta.47",
+    "@workflow/nest": "5.0.0-beta.47",
+    "@workflow/nitro": "5.0.0-beta.47",
+    "@workflow/nuxt": "5.0.0-beta.47",
+    "@workflow/sveltekit": "5.0.0-beta.47",
+    "@workflow/rollup": "5.0.0-beta.47"
   },
   "devDependencies": {
     "@types/ms": "2.1.0",