Uh oh!
There was an error while loading. Please reload this page.
Remove WORKFLOW_SAFE_MODE; configure WORKFLOW_SEQUENTIAL_REPLAYS directly - #2932
Remove WORKFLOW_SAFE_MODE; configure WORKFLOW_SEQUENTIAL_REPLAYS directly#2932VaguelySerious wants to merge 1 commit into
Conversation
…ctly Drop the WORKFLOW_SAFE_MODE umbrella fallback from isSequentialReplaysEnabled() in @workflow/builders and its mirror in @workflow/world-vercel, and remove the safe-mode tests. WORKFLOW_SEQUENTIAL_REPLAYS is now gated only by its own env var. Docs: state what WORKFLOW_SEQUENTIAL_REPLAYS does and note it might lead to higher queue performance overhead; drop the safe-mode references and the other tradeoff/cost callouts. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: dc85e9f The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Workflow Benchmarkscommit Backend:
Avg deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body execution · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (time outside step bodies, client start → last step body exit) · SL: stream latency (first chunk write → visible to the reader) Scenarios — stream: one step that streams chunks back to the client; no hooks, so the run stays in turbo mode · hook + stream: registers a hook before the same streaming step, which exits turbo mode · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges 🟢/🔴 mark percentiles within/above target. Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120 TTFS/WO compare client vs deployment clocks and SL compares the step runner’s clock vs the client’s (NTP-synced in CI). WO ends at the last step body exit, the closest observable proxy for the final step-completion request. |
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
❌ Some E2E test jobs failed:
Check the workflow run for details. |
Drop the WORKFLOW_SAFE_MODE fallback from isPreconditionGuardEnabled() (+ tests); the guard is gated only by WORKFLOW_PRECONDITION_GUARD=1. Remove the WORKFLOW_SAFE_MODE doc section this branch added (v4/v5 Vercel World, v5 worlds config) and the safe-mode mitigation from the corrupted-event-log pages. Reword the runtime-tuning guard entry to state what it does, without perf/correctness framing. Drop SAFE_MODE from the changeset. (The seq-replays SAFE_MODE references still present here are inherited from main and removed by the companion PR #2932; they resolve when this branch rebases.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
VaguelySerious
commented
Jul 15, 2026
Folded into #2266 — the |
Summary
Removes the unreleased
WORKFLOW_SAFE_MODEumbrella flag.WORKFLOW_SEQUENTIAL_REPLAYSis now controlled only by its own environment variable.WORKFLOW_SAFE_MODEwas added alongsideWORKFLOW_SEQUENTIAL_REPLAYS(#2193) but has not shipped in a release, so this is a pre-release cleanup rather than a breaking change.Changes
@workflow/builders/@workflow/world-vercel—isSequentialReplaysEnabled()(and its mirrored copy inworld-vercel) returntrueonly forWORKFLOW_SEQUENTIAL_REPLAYS=1; theWORKFLOW_SAFE_MODEfallback and its tests are removed.WORKFLOW_SEQUENTIAL_REPLAYSdocumentation (Vercel World v4 + v5, worlds configuration, framework integrations) now states what the flag does and notes that it might lead to higher queue performance overhead. The safe-mode references and the other tradeoff/cost callouts are dropped.What
WORKFLOW_SEQUENTIAL_REPLAYSdoesSet
WORKFLOW_SEQUENTIAL_REPLAYS=1to run at most one orchestrator (flow) invocation at a time per workflow run: each run's flow messages get a dedicated queue topic and the flow trigger is generated withmaxConcurrency: 1. Inline step executions get per-step topics and keep full parallelism. Read at both build time and runtime. Routing each run through a dedicatedmaxConcurrency: 1topic might lead to higher queue performance overhead.🤖 Generated with Claude Code