eve
Version:
Filesystem-first framework for durable backend AI agents that run anywhere.
204 lines • 10.5 kB
TypeScript
export declare const MAX_QUEUE_DELIVERIES = 48;
/**
* Effective max queue deliveries. Override via `WORKFLOW_MAX_QUEUE_DELIVERIES`.
*/
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
* (`"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`.
*
* If the non-step ("replay") time within a single invocation exceeds this
* budget, the handler exits so the queue can retry. After
* `REPLAY_TIMEOUT_MAX_RETRIES` exhausted attempts the run is failed with
* `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
* 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.
*
* Override via the `WORKFLOW_REPLAY_TIMEOUT_MS` env var (clamped to
* `MIN_REPLAY_TIMEOUT_MS`..`MAX_REPLAY_TIMEOUT_MS`).
*/
export declare const REPLAY_TIMEOUT_MS = 240000;
/** Lower bound for the replay-timeout env var override. */
export declare const MIN_REPLAY_TIMEOUT_MS = 30000;
/**
* Upper bound for the replay-timeout env var override. 780s leaves ≥20s of
* headroom under Vercel Pro Fluid's 800s function ceiling so the handler
* can write `run_failed` before SIGTERM.
*/
export declare const MAX_REPLAY_TIMEOUT_MS = 780000;
/**
* Resolve the effective replay-timeout budget for the current process.
*
* 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,
* 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
* exercise the warn path repeatedly without sharing state.
*
* @internal
*/
export declare function _resetReplayTimeoutWarnCacheForTests(): void;
export declare const REPLAY_TIMEOUT_MAX_RETRIES = 3;
/**
* Effective replay-timeout retry budget. Override via
* `WORKFLOW_REPLAY_TIMEOUT_MAX_RETRIES`.
*/
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
* round-trips for a `Promise.all`-style fan-out. `1` reproduces the
* single-inline-step behavior exactly (useful kill-switch).
*
* Override via `WORKFLOW_MAX_INLINE_STEPS` (clamped to
* `MIN_MAX_INLINE_STEPS`..`MAX_MAX_INLINE_STEPS`).
*/
export declare const MAX_INLINE_STEPS = 3;
/** Lower bound for the inline-steps env override (1 = single inline step). */
export declare const MIN_MAX_INLINE_STEPS = 1;
/**
* Upper bound for the inline-steps env override. Inline bodies run in parallel
* within one function invocation, so this caps memory/CPU fan-out per handler.
*/
export declare const MAX_MAX_INLINE_STEPS = 16;
/**
* Resolve the effective max number of inline steps for the current process.
*
* 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
* one-time warning so misconfiguration is observable.
*/
export declare function getMaxInlineSteps(): number;
/**
* Optional client-side override for the server-supplied per-run event ceiling.
* When set to a positive integer, the runtime clamps the server's limit *down*
* to this value (never raises it) so enforcement can be exercised without a
* server-side change. `undefined` (unset) ⇒ use the server value as-is.
*
* 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.
*/
export declare function getMaxEventsOverride(): number | undefined;
/**
* Whether optimistic inline step start is enabled. When on, the owned-inline
* path begins running a brand-new step's body *before* its lazy `step_started`
* network call resolves (the input is already known locally), awaiting the
* `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
* 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
* **off by default** and must be explicitly opted into per deployment.
*
* Reads `process.env.WORKFLOW_OPTIMISTIC_INLINE_START` lazily. Default OFF;
* enabled only by an explicit `'1'` / `'true'`.
*/
export declare function isOptimisticInlineStartEnabled(): boolean;
/**
* Whether an operator has **explicitly disabled** optimistic inline start via
* `WORKFLOW_OPTIMISTIC_INLINE_START=0` / `=false`. Distinct from "unset": unset
* leaves the optimization off by default but lets turbo force it on; an explicit
* `0`/`false` is an operator opt-out that turbo must honor (turbo's forced
* optimistic start still runs a step body before `step_started`/`run_started` is
* confirmed, the property such an operator is opting out of), so
* `forceOptimisticStart` defers to this. Reads the env var lazily.
*/
export declare function isOptimisticInlineStartExplicitlyDisabled(): boolean;
/**
* Whether "turbo mode" is enabled. Turbo mode fast-paths the *first delivery of
* 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
* `WORKFLOW_OPTIMISTIC_INLINE_START`.
*
* Forcing optimistic start is safe here because the first delivery has no
* concurrent peer handler to race the step create-claim, so a step body runs
* exactly once. That single-handler guarantee ends as soon as the run creates a
* hook or wait (which introduce resume/parallel invocations), so the runtime
* exits turbo at that point.
*
* Reads `process.env.WORKFLOW_TURBO` lazily. Default **ON**; disabled only by an
* explicit `'0'` / `'false'` (case-insensitive).
*/
export declare function isTurboEnabled(): 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
* 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 —
* the recorded ownerMessageId is inert data when the switch is off.
*/
export declare function isInlineOwnershipEnabled(): boolean;
/**
* Default inline-ownership lease, in seconds: how long after a step's latest
* (stamped) `step_started` a non-owner invocation assumes the owning
* invocation may still be alive. Within the lease, wake replays enqueue the
* step's backstop message with `delaySeconds = lease remaining` instead of
* 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
* `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
* 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
* single-flight layer (step-single-flight.ts) is what makes a backstop
* firing mid-step harmless.
*
* 860 also stays under the queue's 900s maximum delay (SQS cap), so a
* backstop's full lease remainder always fits in a single delayed message.
*
* Override via `WORKFLOW_INLINE_OWNERSHIP_LEASE_SECONDS` (clamped to
* 1..`MAX_INLINE_OWNERSHIP_LEASE_SECONDS`).
*/
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
* 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
* multi-instance worlds with long-running steps to widen the window in which
* a live owner is protected from a concurrent backstop execution.
*/
export declare function getInlineOwnershipLeaseSeconds(): number;
export declare const REPLAY_DIVERGENCE_MAX_RETRIES = 3;
/**
* Effective replay-divergence recovery budget. Override via
* `WORKFLOW_REPLAY_DIVERGENCE_MAX_RETRIES`.
*/
export declare function getReplayDivergenceMaxRetries(): number;
//# sourceMappingURL=constants.d.ts.map