eve 0.47.7 → 0.49.0

package/dist/src/compiled/@workflow/core/runtime/constants.d.ts

@@ -6,7 +6,7 @@ export declare function getMaxQueueDeliveries(): number;
 /**
  * Default maximum time allowed for the *replay* portion of a single workflow
  * handler invocation (in ms). This budget only covers deterministic-replay
- * and workflow-VM execution between step boundaries — inline step bodies
+ * and workflow-VM execution between step boundaries. Inline step bodies
  * (`"use step"` functions invoked via `executeStep`) do NOT count against
  * it. Step bodies are bounded separately by the platform's function
  * `maxDuration` (e.g. 800s on Vercel Pro Fluid) and `NO_INLINE_REPLAY_AFTER_MS`.
@@ -17,7 +17,7 @@ export declare function getMaxQueueDeliveries(): number;
  * `RUN_ERROR_CODES.REPLAY_TIMEOUT`.
  *
  * Note that on Vercel Hobby (standard functions), the platform `maxDuration`
- * is 60s — well below this budget, so the platform SIGTERM will fire first
+ * is 60s, well below this budget, so the platform SIGTERM will fire first
  * and the queue will re-deliver until the visibility window expires. With
  * Fluid Compute on Hobby the per-function ceiling rises to 300s, still
  * under the default budget.
@@ -39,13 +39,13 @@ export declare const MAX_REPLAY_TIMEOUT_MS = 780000;
  *
  * Reads `process.env.WORKFLOW_REPLAY_TIMEOUT_MS` lazily so tests and
  * deployments can override per invocation. Invalid / out-of-range values
- * fall back to a safe value (no throw — the env var is an escape hatch,
+ * fall back to a safe value (no throw: the env var is an escape hatch,
  * not a hard requirement) and emit a one-time warning so misconfiguration
  * is observable.
  */
 export declare function getReplayTimeoutMs(): number;
 /**
- * Reset the warn-once cache. Test-only — exported so unit tests can
+ * Reset the warn-once cache. Test-only: exported so unit tests can
  * exercise the warn path repeatedly without sharing state.
  *
  * @internal
@@ -60,8 +60,8 @@ export declare function getReplayTimeoutMaxRetries(): number;
 /**
  * Default maximum number of steps the owned-inline path runs inline (in
  * parallel) per suspension. The rest are queued to background handlers. Each
- * inline step is created lazily — its `step_created` is folded into the
- * `step_started` that `executeStep` sends — so inlining N steps saves N queue
+ * inline step is created lazily (its `step_created` is folded into the
+ * `step_started` that `executeStep` sends), so inlining N steps saves N queue
  * round-trips for a `Promise.all`-style fan-out. `1` reproduces the
  * single-inline-step behavior exactly (useful kill-switch).
  *
@@ -81,7 +81,7 @@ export declare const MAX_MAX_INLINE_STEPS = 16;
  *
  * Reads `process.env.WORKFLOW_MAX_INLINE_STEPS` lazily so tests and
  * deployments can override per invocation. Invalid / out-of-range values fall
- * back to a safe value (no throw — the env var is an escape hatch) and emit a
+ * back to a safe value (no throw: the env var is an escape hatch) and emit a
  * one-time warning so misconfiguration is observable.
  */
 export declare function getMaxInlineSteps(): number;
@@ -97,8 +97,7 @@ export declare function getMaxInlineSteps(): number;
  * messages on its fast inline path instead of paying an S3 store+fetch
  * double-hop for bytes that already live in the event log. Above this size
  * the dispatch falls back to the sequential path (`step_created` write, then
- * a payload-less queue message). Matches `MAX_INLINE_RESUME_PAYLOAD_BYTES`
- * on the resilient hook resume path.
+ * a payload-less queue message).
  */
 export declare const MAX_RESILIENT_STEP_INPUT_BYTES: number;
 /**
@@ -107,12 +106,13 @@ export declare const MAX_RESILIENT_STEP_INPUT_BYTES: number;
  * step-execution queue publish, carrying the serialized step input in the
  * queue message (`stepInput`) so the consumer can idempotently re-ensure the
  * event if the direct write failed transiently. Mirrors the resilient start
- * (`runInput`) and resilient hook resume (`hookInput`) patterns.
+ * (`runInput`) pattern (and the legacy lazy hook resume's `hookInput`, which
+ * current producers no longer send).
  *
  * **Off by default.** Enable via `WORKFLOW_RESILIENT_STEP_DISPATCH=1`.
  *
  * The queue 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
+ * refused: as a duplicate this replay should stop pursuing, or as a stale
  * write 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
@@ -127,11 +127,11 @@ export declare function isResilientStepDispatchEnabled(): boolean;
  * instead of one write per event. Only engages when the World implements the
  * optional `events.createBatch` AND the run is on slot identity
  * (specVersion >= 6) AND the suspension carries no attribute/hook writes and
- * no resilient step dispatch — everything else keeps the single-event path
+ * no resilient step dispatch. Everything else keeps the single-event path
  * byte-for-byte.
  *
  * Reads `process.env.WORKFLOW_BATCH_TRANSITIONS` lazily. Default **ON**;
- * disabled only by an explicit `'0'` / `'false'` (case-insensitive) — the
+ * disabled only by an explicit `'0'` / `'false'` (case-insensitive), the
  * operator escape hatch that restores the exact prior one-write-per-event
  * path, mirroring `WORKFLOW_TURBO`'s kill-switch shape.
  */
@@ -141,10 +141,10 @@ export declare function isBatchTransitionsEnabled(): boolean;
  * Mirrors the server's transaction budgets with a comfortable margin: each
  * fan-out event costs 2 transaction items server-side (entity + event row)
  * against the 100-item DynamoDB cap, and inline payloads count against a
- * 768 KB byte budget — 32 events stays well under both, and a fan-out larger
- * than this simply commits in successive batches (split batches lose
+ * 768 KB byte budget, so 32 events stays well under both, and a fan-out larger
+ * than this commits in successive batches (split batches lose
  * cross-batch atomicity, which is exactly today's per-event-write crash
- * surface — every batch still converges on retry via per-event 409s).
+ * surface, and every batch still converges on retry via per-event 409s).
  */
 export declare const MAX_BATCH_FANOUT_EVENTS = 32;
 /**
@@ -155,7 +155,7 @@ export declare const MAX_BATCH_FANOUT_EVENTS = 32;
  *
  * Reads `process.env.WORKFLOW_MAX_EVENTS_OVERRIDE` lazily so tests and
  * deployments can override per invocation. Invalid values fall back to unset
- * (no throw — the env var is an escape hatch) and emit a one-time warning.
+ * (no throw: the env var is an escape hatch) and emit a one-time warning.
  */
 export declare function getMaxEventsOverride(): number | undefined;
 /**
@@ -165,7 +165,7 @@ export declare function getMaxEventsOverride(): number | undefined;
  * `step_started` only before the terminal write.
  *
  * This can run a step body more than once when handlers race for the same
- * step's create-claim — both run the body before one wins. That is unsafe for
+ * step's create-claim: both run the body before one wins. That is unsafe for
  * steps with non-idempotent side effects; in particular, two concurrent runs
  * of a step that writes to the workflow stream (e.g. an AI agent streaming
  * tokens) can interleave and corrupt the stream data. So the optimization is
@@ -190,7 +190,7 @@ export declare function isOptimisticInlineStartExplicitlyDisabled(): boolean;
  * the first invocation* of a run (detected by the entrypoint via `runInput`
  * presence + `metadata.attempt === 1`): it backgrounds the `run_started` event
  * creation, skips the initial event-log load (nothing has been written yet),
- * and forces optimistic inline step start for that invocation — independent of
+ * and forces optimistic inline step start for that invocation, independent of
  * `WORKFLOW_OPTIMISTIC_INLINE_START`.
  *
  * Forcing optimistic start is safe here because the first delivery has no
@@ -208,7 +208,7 @@ export declare function isTurboEnabled(): boolean;
  * enabled (default ON). When on, the engine hydrates a VM with the
  * workflow bundle once per function instance, snapshots it, and starts
  * every invocation by restoring the snapshot instead of re-evaluating
- * the bundle — skipping the dominant share of VM startup (measured
+ * the bundle, skipping the dominant share of VM startup (measured
  * ~77ms → ~3ms to first suspension for a 1.3MB bundle). Bundles whose
  * module scope consumes randomness, reads the clock, or replaces a
  * serialization intrinsic are detected at hydrate time and
@@ -233,12 +233,12 @@ export declare function isVmRetentionEnabled(): boolean;
  * Whether inline step ownership is enabled (default ON). When on, the lazy
  * `step_started` that creates an inline step records the owning queue
  * message ID, and wake replays that observe an actively-owned step enqueue a
- * *delayed backstop* message instead of immediately requeueing it — fixing
+ * *delayed backstop* message instead of immediately requeueing it, fixing
  * duplicate inline step execution when a hook/wait wakes a run mid-step
  * (vercel/workflow#2780).
  *
  * `WORKFLOW_INLINE_OWNERSHIP=0` (or `false`) is the kill switch: dispatch
- * reverts to the unconditional immediate requeue. Stamping is unaffected —
+ * reverts to the unconditional immediate requeue. Stamping is unaffected:
  * the recorded ownerMessageId is inert data when the switch is off.
  */
 export declare function isInlineOwnershipEnabled(): boolean;
@@ -250,16 +250,16 @@ export declare function isInlineOwnershipEnabled(): boolean;
  * immediately; past it, they enqueue immediately (today's behavior).
  *
  * Why a fixed 860 and not a value derived from the function's `maxDuration`:
- * neither runtime nor build time can see the resolved value — builders emit
+ * neither runtime nor build time can see the resolved value: builders emit
  * `maxDuration: 'max'`, which the platform resolves per-plan at deploy, and
  * no env var or request-context deadline API exposes the result. The bound
  * comes from a platform rule instead: durations above 800s require explicit
  * per-function numeric config, so a builder-emitted `'max'` resolves to at
- * most 800s — 860s therefore dominates any workflow route's invocation
+ * most 800s, and 860s therefore dominates any workflow route's invocation
  * lifetime plus scheduling slack. Revisit when that ceiling moves (the
  * 30-minute duration beta becoming reachable via `'max'` would invalidate
  * the bound). Worlds without an invocation kill bound (world-local,
- * self-hosted) get no death proof from any constant — there the in-process
+ * self-hosted) get no death proof from any constant. There the in-process
  * single-flight layer (step-single-flight.ts) is what makes a backstop
  * firing mid-step harmless.
  *
@@ -272,13 +272,13 @@ export declare function isInlineOwnershipEnabled(): boolean;
 export declare const INLINE_OWNERSHIP_LEASE_SECONDS = 860;
 /**
  * Upper bound for the lease env override. 900s is the queue's maximum
- * per-message delay (SQS cap) — a longer lease would need delay chaining
+ * per-message delay (SQS cap). A longer lease would need delay chaining
  * like long waits use; clamp instead so one delayed message always suffices.
  */
 export declare const MAX_INLINE_OWNERSHIP_LEASE_SECONDS = 900;
 /**
  * Effective inline-ownership lease. Override via
- * `WORKFLOW_INLINE_OWNERSHIP_LEASE_SECONDS` — e.g. raise it on self-hosted
+ * `WORKFLOW_INLINE_OWNERSHIP_LEASE_SECONDS`, e.g. raise it on self-hosted
  * multi-instance worlds with long-running steps to widen the window in which
  * a live owner is protected from a concurrent backstop execution.
  */

package/dist/src/compiled/@workflow/core/runtime/count-step-started-events.d.ts

@@ -2,16 +2,16 @@ import type { Event } from '#compiled/@workflow/world/index.js';
 /**
  * Scope for {@link countStepStartedEvents}:
  * - `{ type: 'ownedBy', messageId }` counts only starts whose
- *   `eventData.ownerMessageId` matches — i.e. attempts performed by that
+ *   `eventData.ownerMessageId` matches, i.e. attempts performed by that
  *   owning queue message (inline lazy starts and owned-recovery re-stamps).
  * - `{ type: 'totalAttempts' }` estimates the step's genuine attempt total
- *   across its whole lifecycle: unstamped (bare) starts — which only real
- *   queue-dispatched background deliveries write — plus the starts of the
+ *   across its whole lifecycle: unstamped (bare) starts, which only real
+ *   queue-dispatched background deliveries write, plus the starts of the
  *   single most-started owner. A genuine lifecycle has at most one inline
  *   owner phase (ownership is claimed atomically at step creation and
  *   lapses permanently at `step_retrying` or on any bare start), so taking
  *   the max over owners counts that phase's real attempts while invocations
- *   racing on the same batch — which stamp their own one-off message IDs —
+ *   racing on the same batch, which stamp their own one-off message IDs,
  *   contribute at most their single largest count instead of accumulating.
  */
 export type StepStartScope = {
@@ -29,7 +29,7 @@ export type StepStartScope = {
  * Concurrent invocations racing on the same pending batch (stale replays,
  * wake replays, a step message dispatched by a replay that lost the
  * create-claim race, ...) can each write a `step_started` for the same
- * logical attempt — worlds without an atomic start guard (world-local) let
+ * logical attempt. Worlds without an atomic start guard (world-local) let
  * all of them through. Counting those duplicates as "attempts" made the
  * maxRetries ceiling fire on healthy runs and fail them with a false
  * "exceeded max retries" (see workflow#3069).
@@ -37,11 +37,11 @@ export type StepStartScope = {
  * Callers therefore scope the count to the starts their ceiling is actually
  * about via `scope`:
  * - the inline owned-recovery ceiling counts only THIS message's starts
- *   (`ownedBy`) — each real (re)delivery of the owning message stamps its
+ *   (`ownedBy`): each real (re)delivery of the owning message stamps its
  *   `ownerMessageId` on the start it writes, while racing invocations stamp
  *   their own IDs (or none), so they no longer inflate the count;
  * - the background-step ceiling counts the lifecycle attempt total
- *   (`totalAttempts`: bare starts plus the largest single owner's starts) —
+ *   (`totalAttempts`: bare starts plus the largest single owner's starts),
  *   so a step that exhausted part of its budget under inline ownership
  *   before transitioning to queued/bare retries still trips the combined
  *   ceiling, while racers' one-off stamped duplicates don't accumulate, and

package/dist/src/compiled/@workflow/core/runtime/deployment-guard.d.ts

@@ -11,7 +11,7 @@ export type DeploymentAffinityOutcome =
 /** Misrouted and out of budget (or unroutable); `run_failed` recorded. */
  | 'failed';
 /**
- * `spanAttributes` is present only on a misrouted delivery — mismatches are
+ * `spanAttributes` is present only on a misrouted delivery: mismatches are
  * rare, so the presence of `workflow.deployment.pinned_id` on a span *is* the
  * signal that one happened, and `recovered` separates the ones a re-route fixed
  * from the ones that kept misrouting.
@@ -22,7 +22,7 @@ export interface DeploymentAffinityResult {
 }
 /**
  * Arguments handed to a call site's re-enqueue closure. The guard owns the
- * policy — counting, backoff, logging, telemetry, escalation — and the call
+ * policy (counting, backoff, logging, telemetry, escalation) and the call
  * site owns only the shape of the message it needs to put back on the queue.
  */
 export interface ReenqueueArgs {
@@ -42,9 +42,9 @@ export interface ReenqueueArgs {
  * Guards deployment affinity: a run may only execute on the deployment it is
  * pinned to.
  *
- * A run's `deploymentId` is fixed when it starts — the deployment that called
+ * A run's `deploymentId` is fixed when it starts: the deployment that called
  * `start()`, or whatever `start({ deploymentId })` resolved to (an explicit id
- * or `'latest'`) — and no replay or step execution may happen anywhere else:
+ * or `'latest'`). No replay or step execution may happen anywhere else:
  * the bundles here may not match the run's persisted history, and any step
  * dispatched from here derives the per-run encryption key from the wrong
  * deployment's master key, which surfaces as a `RuntimeDecryptionError` the
@@ -58,8 +58,8 @@ export interface ReenqueueArgs {
  * spent, mirroring how a replay divergence gets bounded recovery replays before
  * being recorded as a corrupted event log.
  *
- * Callers must pass a run entity they already have in hand — every call site
- * loads the run for other reasons — so the guard costs no extra round trip.
+ * Callers must pass a run entity they already have in hand (every call site
+ * loads the run for other reasons), so the guard costs no extra round trip.
  * (`world.getDeploymentId()` reads the ambient deployment id, e.g.
  * `VERCEL_DEPLOYMENT_ID`, and does not call the backend either.)
  *
@@ -92,7 +92,7 @@ export declare function guardDeploymentAffinity({ world, run, requestId, retryCo
      * Ordering barrier awaited once a mismatch is confirmed, before either
      * stopping action. Under turbo the `run_started` write is backgrounded, and
      * both outcomes hand the run off (to a `run_failed` here, or to the pinned
-     * deployment's own `run_started`) — so that write must have landed first.
+     * deployment's own `run_started`), so that write must have landed first.
      */
     beforeStop?: () => Promise<void>;
 }): Promise<DeploymentAffinityResult>;

package/dist/src/compiled/@workflow/core/runtime/get-port-lazy.d.ts

@@ -10,9 +10,9 @@ export declare function getPortLazy(): Promise<number | undefined>;
 /**
  * Resets the per-process port cache. Intended for tests; not used on the hot
  * path. Callers must let any in-flight lookup settle (await the pending
- * `getPortLazy()` call) before resetting: clearing `_inFlight` here does not
+ * `getPortLazy()` call) before resetting: clearing `portState.inFlight` here does not
  * cancel an already-scheduled resolution, so a late `.then` could otherwise
- * repopulate `_cachedPort` after the reset and bleed into the next test.
+ * repopulate `portState.cachedPort` after the reset and bleed into the next test.
  */
 export declare function resetPortCacheForTesting(): void;
 /**

package/dist/src/compiled/@workflow/core/runtime/get-world-lazy.d.ts

@@ -9,9 +9,9 @@
  *
  * Resolution order, in priority:
  *
- * 1. `globalThis[WorldCacheKey]` — populated by a successful prior
+ * 1. `globalThis[WorldCacheKey]`: populated by a successful prior
  *    `getWorld()` call. This is the steady-state hot path.
- * 2. `globalThis[GetWorldFnKey]` — populated by the module-load side
+ * 2. `globalThis[GetWorldFnKey]`: populated by the module-load side
  *    effect at the bottom of `./world.ts`. Fires on every server bundle
  *    that reaches this file via `workflow` or `workflow/api` (which import
  *    `./world-init.ts` for its side effect; see that file for the full

package/dist/src/compiled/@workflow/core/runtime/helpers.d.ts

@@ -20,7 +20,7 @@ export interface HealthCheckResult {
     /**
      * `@workflow/core` version of the responding deployment, used for
      * capability detection (see `getRunCapabilities`). Omitted when the
-     * responding deployment did not provide the field as a string —
+     * responding deployment did not provide the field as a string:
      * for example, an older `@workflow/core` that predates this field,
      * or a non-JSON plain-text health response.
      */
@@ -35,15 +35,15 @@ export interface HealthCheckResult {
      */
     encryptionPublicKey?: string;
     /**
-     * The responding deployment's `HOOK_RESUME_INPUT_VERSION` — the protocol
-     * version at which the *consumer* (queue-message target) re-ensures the
+     * The responding deployment's `HOOK_RESUME_INPUT_VERSION`: the protocol
+     * version at which the *consumer* (queue-message target) materializes the
      * `hook_received` event from `hookInput` on replay. A cross-deployment
      * `start()` stamps the *target's* value (not the caller's) into the new
-     * run's `executionContext.hookResumeInputVersion` so that `resumeHook()`
-     * only takes the parallel path when the deployment that will actually
-     * consume the queue message is known to honor `hookInput`. Omitted when the
-     * responding deployment predates this field (an older consumer that ignores
-     * `hookInput`), which fails the gate closed.
+     * run's `executionContext.hookResumeInputVersion`. Current producers write
+     * the event durably before publishing the wake and do not read the marker;
+     * OLDER producers still gate their lazy path on it, so it keeps being
+     * stamped. Omitted when the responding deployment predates this field,
+     * which fails that gate closed.
      */
     hookResumeInputVersion?: number;
 }
@@ -75,7 +75,7 @@ export interface HealthCheckOptions {
      * Queue namespace of the target deployment (e.g. `'eve'` for topics like
      * `__eve_wkf_workflow_*`). Falls back to `WORKFLOW_QUEUE_NAMESPACE` in the
      * calling process. Cross-context callers (e.g. the observability
-     * dashboard) must pass the target deployment's namespace explicitly —
+     * dashboard) must pass the target deployment's namespace explicitly:
      * the env fallback resolves in the caller's process, and a message
      * published to a mismatched topic has no consumer, so the check would
      * always time out.
@@ -93,7 +93,7 @@ export declare function healthCheck(world: World, options?: HealthCheckOptions):
  * re-sorted. Every append source is already in canonical order relative to the
  * tail (a cursor-delimited page, or a write-response delta), so receipt order is
  * the order to keep, and re-sorting here would only cost a pass over the log.
- * Nothing downstream may assume the tail is the newest event — see
+ * Nothing downstream may assume the tail is the newest event. See
  * {@link maxEventSlot}.
  */
 export declare function appendUniqueEvents(target: Event[], events: readonly Event[], targetIds?: Set<string>): void;
@@ -104,7 +104,7 @@ export declare function appendUniqueEvents(target: Event[], events: readonly Eve
  *
  * `preloadedEvents` is loaded `sortOrder: 'asc'` and is never re-sorted
  * client-side, so a `hook_received` spliced in by the lazy-resume consumer must
- * land in `eventId` order — a plain `push` would place a late-committing
+ * land in `eventId` order: a plain `push` would place a late-committing
  * earlier event after events that sort before it, corrupting replay.
  *
  * Lexicographic string order is the log's order: a slot id is a fixed-width
@@ -190,7 +190,7 @@ export interface SkippedSlotReport {
  * would raise the log's highest position past a position whose event is
  * missing. Later writes read that maximum to say what they have seen, so each
  * would claim a position it never saw, and the World only reports the span a
- * write skips — it would never send the missing one. Dropping costs one more
+ * write skips: it would never send the missing one. Dropping costs one more
  * round of the same events on the next write and keeps the log a prefix of the
  * truth, which the note above {@link mergeReportedEvents} explains is always an
  * available answer.
@@ -265,7 +265,7 @@ export declare function findEventSlotGap(events: readonly Event[]): EventSlotGap
  *
  * A hole can be transient. The World allocates a slot inside the insert that
  * occupies it, so two concurrent writers can collide, one retry past the other,
- * and the higher slot commit first — leaving a window in which the lower one is
+ * and the higher slot commit first, leaving a window in which the lower one is
  * genuinely absent from a strongly-consistent read and fills in a moment later.
  * The window is one commit wide, so a short backoff clears it; anything that
  * survives all three re-reads is a position no write will ever occupy.
@@ -276,7 +276,7 @@ export declare const SLOT_GAP_RECHECK_ATTEMPTS = 3;
  * out, and return the settled log alongside the hole that survived.
  *
  * Reads are strongly consistent, so a hole is not an artifact of *when* the log
- * was read — but it can be an artifact of a write that had not committed yet
+ * was read, but it can be an artifact of a write that had not committed yet
  * (see {@link SLOT_GAP_RECHECK_ATTEMPTS}). Distinguishing the two costs a
  * re-read, which is only ever paid by a replay that already found a hole.
  *
@@ -295,7 +295,7 @@ export declare function settleEventSlotGap(runId: string, loaded: LoadedEventLog
  * One integer says it because the World keeps its positions dense: a writer
  * that names slot N is claiming to hold every event from 1 to N and nothing
  * above. The World answers by numbering the write above whatever the log has
- * actually reached and handing back the events on the slots in between — the
+ * actually reached and handing back the events on the slots in between: the
  * ones this writer decided without.
  *
  * Density is the World's invariant, not a claim about this particular read. A
@@ -326,14 +326,14 @@ export declare function slotSnapshotParams(events: readonly Event[]): SlotSnapsh
  * The events a rejecting World attached to a `PreconditionFailedError`, when it
  * returned the ones the client's snapshot was missing inline.
  *
- * Returns `null` for anything else — no details, a World that did not implement
+ * Returns `null` for anything else: no details, a World that did not implement
  * this, or a payload that does not narrow cleanly. Callers fall back to
  * reloading the event log, which is always correct; this is untrusted-shaped
  * data on a failure path, so nothing here is repaired.
  *
  * `runId` is the caller's run. Every event must belong to it: the delta is
  * merged straight into the replay's log, and one foreign event there is a
- * corrupt log rather than a corrected one — the replay would consume a
+ * corrupt log rather than a corrected one: the replay would consume a
  * correlation id for an event that does not exist on this run.
  */
 export declare function preconditionEventDelta(error: unknown, runId: string): {
@@ -349,19 +349,19 @@ export type EventCreator = (data: CreateEventRequest, params?: CreateEventParams
 export declare function withHealthCheck(handler: (req: Request) => Promise<Response>, worldSpecVersion?: number): (req: Request) => Promise<Response>;
 /**
  * Idempotency key for a step's background-dispatch queue message, scoped to
- * the step's IDENTITY — correlation id plus (hashed) step name — rather than
+ * the step's IDENTITY, correlation id plus (hashed) step name, rather than
  * the bare correlation id.
  *
  * The scoping matters for resilient step dispatch under the precondition
  * guard: a guard-rejected `step_created` leaves its (revoked) step message in
  * flight, and the corrected replay may re-derive the same correlation id for
  * a DIFFERENT step. Under a bare-correlationId key the corrected replay's
- * dispatch would silently dedupe against the revoked in-flight message —
+ * dispatch would silently dedupe against the revoked in-flight message,
  * which then resolves `skipped` against the re-created entity (the server's
- * stepName fence rejects its bare start) — and the legitimate step would
+ * stepName fence rejects its bare start), and the legitimate step would
  * never be executed. Scoping by step name keeps every dedup property that
  * matters (crash recovery re-dispatch, concurrent handlers, the delayed
- * retry sharing the suspension re-dispatch's key — all name the same step)
+ * retry sharing the suspension re-dispatch's key: all name the same step)
  * while letting the corrected schedule's dispatch through.
  *
  * Every producer of a step-dispatch (or step-retry) message must use this
@@ -382,34 +382,15 @@ export declare function getQueueOverhead(message: {
     [k: string]: number;
 } | undefined;
 /**
- * Returns a memoized accessor for a run's full encryption capability.
- *
- * The first call resolves the run's key material via
- * `world.getEncryptionKeyForRun` (which may do HKDF derivation locally on
- * Vercel, or a network fetch from external contexts) and derives a
- * {@link PayloadKey} from it; subsequent calls await the same cached promise.
- * If the world doesn't support encryption or the run has no key configured,
- * the cached value is `undefined`.
- *
- * The resolved value is deliberately the *full* capability — the symmetric AES
- * key plus the run's X25519 keypair — not just a `CryptoKey`. A run reading
- * its own event log can encounter sealed (`encp`) payloads that another run
- * wrote to it (a cross-deployment hook resumption, say), and opening those
- * needs the keypair. Resolving only the symmetric key would leave those
- * payloads unopenable and wedge the run.
- *
- * Used by step / workflow handlers to defer the (potentially expensive)
- * key fetch until the first code path that actually needs it — typically
- * input hydration on the success path, or error dehydration on a failure
- * path. Both paths can race-call the accessor without triggering duplicate
- * fetches.
- *
- * Errors thrown by `getEncryptionKeyForRun` propagate to every caller
- * (the cached promise rejects). This is intentional: when encryption is
- * configured, we never want to silently fall back to plaintext
- * serialization. A propagated error in an event-emission path leaves the
- * outer try/catch to log and surface the issue; the queue's redelivery
- * semantics will retry the key fetch on the next attempt.
+ * Resolve the run's full payload-encryption capability. This includes the
+ * symmetric key and X25519 keypair needed to open cross-run sealed payloads.
+ * Missing world support or key material resolves to `undefined`; lookup and
+ * derivation failures propagate rather than silently falling back to plaintext.
+ */
+export declare function resolveRunEncryptionKey(world: World, runOrId: WorkflowRun | string, context?: Record<string, unknown>): Promise<PayloadKey | undefined>;
+/**
+ * Return a lazy, memoized accessor around {@link resolveRunEncryptionKey}.
+ * Concurrent callers share the same promise, including its rejection.
  */
 export declare function memoizeEncryptionKey(world: World, runOrId: WorkflowRun | string): () => Promise<PayloadKey | undefined>;
 //# sourceMappingURL=helpers.d.ts.map

package/dist/src/compiled/@workflow/core/runtime/quickjs-entrypoint.d.ts

@@ -1,9 +1,9 @@
 /**
- * QuickJS VM integration with the Workflow DevKit.
+ * QuickJS WebAssembly (WASM) VM integration with the Workflow DevKit.
  *
  * This module provides the entry point for running workflows in the
- * QuickJS WASM VM engine instead of the `node:vm` engine. Both engines
- * implement the same event-replay execution model — every invocation:
+ * QuickJS VM engine instead of the `node:vm` engine. Both engines
+ * implement the same event-replay execution model, where every invocation:
  *
  * 1. Loads the full event log for the run
  * 2. Runs the workflow function from the top in a fresh QuickJS VM,
@@ -16,7 +16,7 @@ import type { Span } from '#compiled/@opentelemetry/api/index.js';
 import { type Event, type RunInput, type WorkflowRun } from '#compiled/@workflow/world/index.js';
 /**
  * Returns true when the supplied preloaded events indicate this is the
- * first workflow handler invocation for the run — i.e. the log contains
+ * first workflow handler invocation for the run, i.e. the log contains
  * nothing beyond `run_created` / `run_started`. In that case the
  * preloaded events ARE the complete event log and the `events.list`
  * round-trips can be skipped entirely.
@@ -38,12 +38,12 @@ export declare function isFirstInvocation(preloadedEvents: readonly Event[] | un
  * This replaces the `node:vm` replay path (runWorkflow + EventsConsumer)
  * with a QuickJS VM invocation that performs the same full event replay.
  *
- * KNOWN GAP — slot snapshot: unlike the node:vm path, no event write in
+ * KNOWN GAP (slot snapshot): unlike the node:vm path, no event write in
  * this file carries {@link CreateEventParams.eventCount}, so a World never
  * learns which events the writer had not seen and never reports them back.
  * The engine currently relies on per-(runId, correlationId) event
  * uniqueness (EntityConflictError dedup) alone. This is a deliberate
- * simplification while the engine is experimental — wiring the snapshot is
+ * simplification while the engine is experimental: wiring the snapshot is
  * tracked follow-up work; anyone adding new write paths here should not
  * assume parity with the node engine on this axis.
  */
@@ -54,8 +54,8 @@ export declare function runWorkflowWithQuickJS(params: {
     /**
      * Events returned inline by `events.create('run_started', ...)` or by
      * the lazy hook fast path's `hook_received` preload. When they indicate
-     * a first invocation — or when `preloadedEventsComplete` attests they
-     * are the complete log — they are used as the event log instead of
+     * a first invocation, or when `preloadedEventsComplete` attests they
+     * are the complete log, they are used as the event log instead of
      * fetching via `events.list`, matching the node:vm engine's fast path.
      */
     preloadedEvents?: Event[];
@@ -106,8 +106,8 @@ export declare function runWorkflowWithQuickJS(params: {
     /**
      * Queue namespace resolved at route registration (runtime.ts). Must be
      * threaded into every message publish: the builders bake the namespace
-     * into generated routes, so consumers listen on `__<ns>_wkf_workflow_*`
-     * — a publish without it lands on `__wkf_workflow_*` and is never
+     * into generated routes, so consumers listen on `__<ns>_wkf_workflow_*`.
+     * A publish without it lands on `__wkf_workflow_*` and is never
      * picked up.
      */
     namespace?: string;
@@ -119,6 +119,17 @@ export declare function runWorkflowWithQuickJS(params: {
      * invocations to each other and fragment the run view on async queues.
      */
     nextTraceCarrier?: () => Promise<Record<string, string>>;
+    /**
+     * The wait this invocation is the delayed continuation for, if it is one
+     * (`WorkflowInvokePayload.waitContinuation`). Read only to decide the next
+     * continuation's idempotency key: a continuation that finds its own wait
+     * still pending has spent its key, so the re-arm has to advance the attempt
+     * or the world's dedupe window drops it and the wait loses its only timer.
+     */
+    waitContinuation?: {
+        correlationId: string;
+        attempt: number;
+    };
 }): Promise<{
     timeoutSeconds?: number;
 } | void>;