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