Uh oh!
There was an error while loading. Please reload this page.
test(e2e): force storage-backed inspect listings (read-your-writes) via WORKFLOW_DISABLE_ANALYTICS_READS - #3062
Conversation
🦋 Changeset detectedLatest commit: 49fe560 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:
📜 Previous results (2)d1a0ee2Thu, 23 Jul 2026 19:00:00 GMT · run logs
b9f18ecThu, 23 Jul 2026 05:36:51 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
✅ 📋 Other
✅ vercel-multi-region
❌ Some E2E test jobs failed:
Check the workflow run for details. |
…_ANALYTICS_READS The analytics store ingests asynchronously; e2e assertions read events and steps immediately after run completion and can catch a page missing the freshest rows (observed as stepFunctionPassingWorkflow's step_completed readback returning empty, and the same race on steps listings in other suites). Instead of polling each readback, disable the analytics namespace for the e2e's CLI invocations so every inspect listing is served read-your-writes from primary storage. Replaces the earlier bounded poll with the deterministic mechanism. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
d1a0ee2 to
49fe560CompareUh oh!
There was an error while loading. Please reload this page.
No backport to This change builds entirely on the analytics read namespace ( To override, re-run the Backport to stable workflow manually via |
Problem
The e2e suites assert on
workflow inspectlistings (events, steps) immediately after run completion. Those listings prefer the world'sanalyticsread namespace, which is served from an eventually-ingested store — a read racing ingestion can return a page that includes the run's earlier rows but not the freshest ones, so the CLI's empty-page storage fallback doesn't trigger and the assertion fails.Observed fingerprints (all with the run demonstrably completed with correct status/output):
stepFunctionPassingWorkflow:expected [] to have a length of 1on thestep_completedevents readback (two CI occurrences on different lanes).instanceMethodStepWorkflow:counterSteps.every(status === 'completed')false on the steps listing — same race, different resource (two occurrences on different lanes/days).Fix
Deterministic rather than bounded-wait (supersedes the earlier poll commit):
@workflow/world-vercel:WORKFLOW_DISABLE_ANALYTICS_READS=1opts the world'sanalyticsnamespace off, so every inspect list path falls back to strongly consistent primary storage.cliInspectJsonsets that env for its spawned CLI invocations — every entity readback in the suites becomes read-your-writes, covering both observed variants and any future listing assertions, with no per-test changes.Production behavior is unchanged (the env is opt-in); the analytics-backed listings remain the CLI default everywhere else.
🤖 Generated with Claude Code