Uh oh!
There was an error while loading. Please reload this page.
Default WORKFLOW_PRECONDITION_GUARD on - #2946
Conversation
Follow-up to #2266 (review pullrequestreview-4699625704). - **Guard on by default:** `isPreconditionGuardEnabled()` now returns true unless `WORKFLOW_PRECONDITION_GUARD` is explicitly falsy. Validated by the #2266 race-repro (2000 runs guard-on: 0 corruptions). - **Env-var footgun:** boolean flags accept `1`/`true`/`yes`/`on` (and `0`/`false`/`no`/`off` for the guard's opt-out) case-insensitively instead of only `1`, so `=true` no longer silently reads as off. Mirrored across `isPreconditionGuardEnabled` (core) and `isSequentialReplaysEnabled` (builders + world-vercel). - **run_failed asymmetry:** comment documenting why the terminal `run_failed` is intentionally not guarded (fail-open, re-runnable) unlike `run_completed`. - **Concurrent-reload cursor:** comment on the benign last-write-wins cursor in withPreconditionRetry. - **World-authoring docs:** CreateEventParams.stateUpdatedAt JSDoc now documents the backend marker/reject/equal-passes contract for custom-world authors. - **Diagnostics:** debug log when a non-decodable event id disarms the guard. - **retryAfter:** JSDoc noting it is forward-compat and currently unused. - Docs: runtime-tuning guard entry updated to "Default: enabled" + opt-out. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 17ec74f The changes in this PR will be included in the next version bump. This PR includes changesets to release 21 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:
📜 Previous results (4)cf4bdbaMon, 20 Jul 2026 21:10:52 GMT · run logs
ae65171Sat, 18 Jul 2026 00:21:01 GMT · run logs
304f594Wed, 15 Jul 2026 20:54:37 GMT · run logs
45a9425Wed, 15 Jul 2026 19:57:19 GMT · run logs
Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) 🔴 marks a percentile over its target (within target is left unmarked). 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 All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
…ard-followup # Conflicts: # docs/content/docs/v5/configuration/runtime-tuning.mdx
No backport to This commit is a follow-up to #2266's To override, re-run the Backport to stable workflow manually via |
Summary
Follow-up to #2266. Two things:
WORKFLOW_PRECONDITION_GUARDis now on by default. The event-creation guard was opt-in; it now runs unless explicitly disabled withWORKFLOW_PRECONDITION_GUARD=0. Backends that don't support the guard ignore thestateUpdatedAtsnapshot, so this is backward-compatible and fails open. Validated by the Add stateUpdatedAt precondition guard to event creation #2266 race-repro (2000 runs guard-on: 0CORRUPTED_EVENT_LOG, 13.8% of runs hit a 412 and recovered).Addresses the non-blocking feedback from this review
Review items addressed
1/true/yes/on,0/false/no/off) instead of only1will ship on its own, so this PR leaves the flag parsing (and@workflow/builders/@workflow/world-vercel) untouched.run_failedasymmetry — added a comment documenting why the terminalrun_failedis intentionally not guarded likerun_completed(fail-open: a spurious failure is re-runnable, a spurious completion commits a wrong result; and the loaded event log isn't in scope on that catch path). Guarding it symmetrically would be a larger change — happy to do it as its own follow-up if preferred.CreateEventParams.stateUpdatedAtJSDoc now documents the backend contract (which events advance the per-run marker, strictly-older rejects, equal-passes anti-livelock) so custom-World authors have something to implement against.withPreconditionRetry.runtimeLogger.debugwhen a non-decodable event id disarms the guard for a create.retryAfternit — JSDoc noting it's forward-compat and currently unread by the runtime.