Skip to content

[test] Add nextjs eager discovery e2e test workbench#1713

Open
VaguelySerious wants to merge 8 commits intofix/next-build-econnrefused-and-dynamic-importfrom
peter/eager-discovery-workbench
Open

[test] Add nextjs eager discovery e2e test workbench#1713
VaguelySerious wants to merge 8 commits intofix/next-build-econnrefused-and-dynamic-importfrom
peter/eager-discovery-workbench

Conversation

@VaguelySerious
Copy link
Copy Markdown
Member

@VaguelySerious VaguelySerious commented Apr 13, 2026

I'll add the vercel project + prod e2e once this PR is merged, so that the build doesn't fail on other PRs

christopherkindl and others added 5 commits April 11, 2026 17:18
…sition (#1694)

The global `scroll-smooth` CSS class on <html> caused Next.js navigation
scroll-to-top to animate instead of jumping instantly, making cross-page
links appear stuck at the previous scroll position.

Signed-off-by: christopherkindl <53372002+christopherkindl@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add cookbook section with 50 workflow pattern recipes

Migrate the "Workflow API Explorer" decision tree concept from
workflow-campaign-demos into useworkflow.dev docs as a Cookbook.

Infrastructure:
- docs/lib/cookbook-tree.ts: decision tree data, 50 recipe metadata entries, slug-to-category mapping
- docs/components/geistdocs/cookbook-explorer.tsx: interactive "I want to..." decision tree UI with breadcrumb navigation
- docs/content/docs/cookbook/index.mdx: landing page rendering CookbookExplorer component
- docs/content/docs/cookbook/meta.json + 8 category meta.json files for sidebar nav
- docs/content/docs/meta.json: added cookbook to docs nav between foundations and how-it-works
- docs/app/[lang]/docs/[[...slug]]/page.tsx: registered CookbookExplorer component

50 recipe MDX files across 8 categories (payments, approvals, resilience,
notifications, webhooks, data-processing, routing, observability), each with:
- Frontmatter (title, description, type: guide, summary with use-case scenario)
- Simplified code snippet (core pattern only, stripped of demo UI concerns)
- Full implementation code snippet (exact source from campaign demos)
- Key APIs section with links to API reference docs

* ploop: iteration 1 checkpoint

Automated checkpoint commit.

Ploop-Iter: 1

* fix: polish cookbook public routing

Keep the cookbook surface canonical at /cookbooks so docs navigation, sitemap output, and AI/chat entry points stop leaking the legacy /docs/cookbook paths.

Correct the approval-chain example so the docs teach the intended sequential approval semantics instead of implying the workflow approves after the first successful level. This keeps the cookbook aligned with the docs quality bar and avoids misleading readers with inconsistent behavior.

Ploop-Iter: 2

* docs: canonicalize cookbook doc routes

Align cookbook-facing docs outputs with the new public route so
redirects, sitemap entries, and LLM-facing exports stay consistent.
This keeps the polished cookbook section discoverable at its canonical
location while trimming the last demo-heavy recipe examples toward the
same concise style as the rest of the docs.

Ploop-Iter: 3

* ploop: iteration 4 checkpoint

Automated checkpoint commit.

Ploop-Iter: 4

* fix(docs): finalize cookbook route split

Keep cookbook content discoverable after moving it to a first-class /cookbooks surface so navigation, canonical metadata, and markdown consumers resolve the new public URLs consistently.

Avoid serving the legacy /docs/cookbook tree as if it were still part of the docs section, which reduces duplicate navigation paths and prevents stale static output from competing with the new route structure.

Ploop-Iter: 5

* docs: improve cookbook discovery

The cookbook landing page needs to work for both exploratory users and users who already know the pattern they want. This keeps the guided decision tree while adding shared category metadata and a searchable browse mode so recipe discovery feels faster and more consistent with the rest of the docs experience.

Ploop-Iter: 6

* docs: refine cookbook pattern examples

Tighten the simplified cookbook recipes so the examples teach the intended workflow semantics clearly and consistently. The changes keep the documentation focused on the core control-flow patterns reviewers called out, while removing ambiguity around partial arrivals, deadlines, and first-success behavior.

Ploop-Iter: 7

* docs: decouple cookbook sidebar tree

Separate cookbook navigation from the docs page tree so the standalone /cookbooks experience stays stable after the route move and the main docs sidebar no longer leaks cookbook entries.\n\nThis keeps cookbook navigation driven by explicit recipe metadata, which avoids duplicated section titles and makes the docs and cookbook surfaces easier to evolve independently.\n\nPloop-Iter: 8

* fix(docs): align cookbook public nav

Keep cookbook pages on their public /cookbooks surface so metadata and copied markdown do not leak legacy /docs/cookbook paths.\n\nSimplify sidebar rendering to trust the injected page tree, which avoids route-specific filtering and keeps cookbook navigation consistent with the active layout tree.\n\nPloop-Iter: 9

* refactor(docs): decouple cookbook routing

Move cookbook rendering off the shared docs route so cookbook pages can behave like a first-class docs surface without leaking cookbook-specific UI into the main docs experience.

Centralizing cookbook tree filtering keeps sidebar behavior consistent in one place and avoids duplicate cookbook navigation state across layouts.

Ploop-Iter: 10

* docs: improve cookbook explorer accessibility

Improve the cookbooks entrypoint so loading and keyboard navigation
are usable without visual cues, and keep guided and browse modes
resilient while the route hydrates.

Ploop-Iter: 11

* ploop: iteration 12 checkpoint

Automated checkpoint commit.

Ploop-Iter: 12

* docs: rename cookbooks route to cookbook (singular)

* docs: add 5 cookbook overview design variations

Add getRecipeHref, getRecipesByCategory, and collectSlugs helpers to
cookbook-tree.ts, then create 5 distinct overview page variations at
/cookbook/v1 through /cookbook/v5 for side-by-side comparison:

- v1: Category Grid (zero-JS scannable overview)
- v2: Search-First (real-time filtering with category pills)
- v3: Accordion Catalog (expandable category sections)
- v4: Decision Wizard (step-by-step guided questions)
- v5: Problem-Solution Table (master-detail by scenario)

Also adds .impeccable.md with project design context.

* docs: remove unrelated package.json bumps and generated artifacts

* docs: restructure cookbook from 50 recipes into 27 consolidated pages

Restructure the cookbook based on team meeting feedback, toolbar comments,
mux-ai pattern analysis, and Vercel org code search. Consolidates duplicates,
adds missing patterns, ensures all examples have proper directives and
type-check against the real workflow SDK.

New structure:
- common-patterns/ (9): saga, batching, rate-limiting, fan-out,
  scheduling, idempotency, webhooks, content-router, child-workflows
- agent-patterns/ (5): durable-agent, tool-streaming,
  human-in-the-loop, tool-orchestration, stop-workflow
- integrations/ (3): ai-sdk, sandbox, chat-sdk
- advanced/ (6): serializable-steps, durable-objects,
  isomorphic-packages, secure-credentials, custom-serialization,
  publishing-libraries

All 92 code snippets pass docs-typecheck against real workflow SDK types.
Deleted 8 old category folders. Updated cookbook-tree.ts, explorer, nav.

* docs: add workflow migration guides

Help teams evaluating the GA launch translate existing durable workflow systems into Vercel Workflow without reverse-engineering concept parity from product docs alone.

The guides focus on real migration decisions and concrete TypeScript examples so adoption can be driven by implementation clarity rather than platform marketing.

Ploop-Iter: 1

* ploop: iteration 2 checkpoint

Automated checkpoint commit.

Ploop-Iter: 2

* docs: refine workflow migration guides

Clarify the migration narrative for GA so teams evaluating a move from Temporal, Inngest, or Step Functions get examples that are realistic enough to trust and pricing guidance that matches the current platform model.

The Inngest guide needed a complete order-saga flow so the durable orchestration, compensation, and streaming patterns read as a credible migration target instead of a partial sketch. The pricing language across all three guides also needed to be aligned with current Workflow and Vercel compute billing semantics to avoid creating the wrong cost expectations during evaluation.

Ploop-Iter: 3

* ploop: iteration 1 checkpoint

Automated checkpoint commit.

Ploop-Iter: 1

* docs(skill): refine workflow migration guidance

Clarify migration rules so agents choose the correct resume primitive, keep streaming guidance aligned with runtime behavior, and avoid implying Vercel-managed execution for self-hosted targets.

This reduces avoidable migration mistakes in generated guidance and keeps the skill consistent with the acceptance criteria used to evaluate it.

Ploop-Iter: 2

* ploop: iteration 3 checkpoint

Automated checkpoint commit.

Ploop-Iter: 3

* docs(skills): refine workflow migration guidance

Reduce the migration skill entry point to the decision surface agents need\nso they can select the correct resume pattern without carrying duplicate\nexamples in the initial context.\n\nClarify framework precedence so prompts that explicitly ask for\nframework-agnostic boundaries do not get Hono- or Next-specific route\nshapes, while preserving framework-specific examples when requested.\n\nCentralize canonical resume examples in the shared patterns reference to\nkeep the guidance consistent across migration paths and reduce drift.\n\nPloop-Iter: 4

* docs: add workflow deep-dive references

Add a cohesive set of deep-dive reference articles so the GA launch
has architecture-level documentation grounded in the current SDK
implementation. This gives readers verified explanations of runtime,
replay, streaming, compiler, and cost-model behavior while linking the
series together for easier navigation.

Ploop-Iter: 1

* ploop: iteration 5 checkpoint

Automated checkpoint commit.

Ploop-Iter: 5

* docs: normalize deep-dive related links

Keep the new deep-dive reference pages cross-linked so readers can move between adjacent runtime concepts without depending on older how-it-works pages alone.

This preserves navigational consistency across the GA launch docs set and reduces the chance that architectural explanations drift into isolated pages that are harder to discover and maintain.

Ploop-Iter: 2

* docs(skill): refine workflow migration routing

Tighten the migration guidance so agents choose the correct resume surface and runtime boundary earlier, reducing incorrect mixed patterns in generated migrations.

Add explicit fast paths for self-hosted targets and Step Functions task-token callbacks so the skill stays consistent on callback URL vs deterministic resume decisions.

Ploop-Iter: 6

* docs: refine workflow migration skill guidance

Clarify route selection so the migration skill composes resume, runtime, and app-boundary concerns deterministically. Add a canonical Step Functions self-hosted Hono callback recipe so migrations produce the correct callback-url pattern without mixing incompatible hook surfaces.\n\nPloop-Iter: 7

* docs: checkpoint deep-dive drafts

Preserve the verified GA launch deep-dive drafts in git so the campaign work can continue from a stable checkpoint.

Capture the reviewed documentation progress now to reduce risk of drift between source-backed research and the publishable drafts.

Ploop-Iter: 3

* docs(skills): tighten workflow migration routing

Clarify the migration skill's route-selection rules so generated guidance stays consistent across resume surfaces, runtime targets, and named framework boundaries.

This reduces ambiguous outputs where agents might mix framework syntaxes or invent callback routes for webhook-based flows, which leads to migration guidance that does not match the user's runtime model.

Ploop-Iter: 8

* docs: finalize workflow deep dives

Clarify the runtime mechanics behind the GA deep-dive series so launch content stays aligned with the implementation and existing docs. Tightening these explanations reduces the risk of readers internalizing inaccurate mental models about replay, compilation, and workflow execution.\n\nPloop-Iter: 4

* docs(skills): refine workflow migration routing

Clarify route selection so migrations choose the correct resume surface and app boundary patterns for the target runtime and framework. Strengthen verification guidance to reject invented callback routes in URL-based flows and keep examples aligned with the documented migration rules.

Ploop-Iter: 9

* docs: sync compiler deep-dive runtime details

Align the compiler deep-dive trio with the actual Workflow runtime so launch materials describe the same execution model users rely on. This keeps the GA narrative accurate around deterministic replay, step queue triggers, and runtime bundle responsibilities, reducing the risk of docs teaching an architecture the SDK does not implement.

Ploop-Iter: 5

* docs(skill): tighten workflow migration guidance

Reduce hot-path skill context so migration routing stays easier to select and
verify during activation.

Trimmed examples and converted long invalid samples into concise failure rules
so the skill points agents to on-demand references instead of loading bulky
worked code by default.

Ploop-Iter: 10

* docs: tighten workflow migration guidance

Clarify route-key planning and resume-surface defaults so migration outputs
stay deterministic when prompts underspecify callback behavior.

Strengthen the deep-dive docs to trace runtime handoffs more directly,
which reduces ambiguity about how the compiler split maps to durable
execution behavior.

Ploop-Iter: 11

* docs: refine streaming and cost deep dives

Clarify the operational model behind durable streaming and zero-cost suspension so launch materials stay source-accurate for readers comparing workflow runtimes.

The updates make the workflow-step boundary, persistence path, and queue-driven cost story more explicit, reducing ambiguity around where stream I/O is allowed and why long waits do not consume compute.

Ploop-Iter: 6

* ploop: iteration 12 checkpoint

Automated checkpoint commit.

Ploop-Iter: 12

* docs: tighten deep-dive streaming accuracy

Align the launch deep dives with the current runtime so campaign content does not misstate suspension behavior or streaming backend capabilities.

These edits clarify the distinct resume paths for step suspension versus timed waits and document the backend-specific streaming guarantees now available across local, Vercel, and Postgres worlds, reducing the risk that readers build incorrect mental models from launch materials.

Ploop-Iter: 7

* docs(skills): refine callback resume taxonomy

Clarify when migrations should use deterministic internal resume versus generated callback URLs so skill outputs stay consistent across frameworks and hosting targets. Distinguish default webhook responses from manual-response flows to prevent ambiguous guidance and keep the shared callback references directly inspectable.\n\nPloop-Iter: 13

* docs: refine deep-dive runtime wording

Clarify the runtime semantics behind suspension and durable streaming so the GA launch materials stay aligned with the source of truth.

These edits tighten descriptions around wake-up paths, backend behavior, and stream lifecycle details to reduce ambiguity for readers comparing the docs to the implementation.

Ploop-Iter: 8

* docs: clarify webhook response mode defaults

Clarify when migrations should use the default webhook behavior versus
manual responses so agents make the same callback choice across the
skill entrypoint, shared patterns, and API reference.

This reduces avoidable ambiguity for callback-url prompts and makes the
default 202 behavior explicit unless a prompt requires custom response
semantics.

Ploop-Iter: 14

* docs: align cost model wake-up semantics

Prevent the GA launch materials from teaching an incorrect mental model about how suspended runs wake back up. The updated wording keeps the blog, social, and reference variants anchored to the real runtime paths so readers understand which transitions are queue-delayed, which are step-driven re-enqueues, and why that distinction matters for the cost story.

Ploop-Iter: 9

* ploop: iteration 10 checkpoint

Automated checkpoint commit.

Ploop-Iter: 10

* docs: clarify webhook resume choices

Explain the resume-surface decision points so migration and API guidance steer authors toward the correct webhook or hook pattern for the prompt.

Reduce common callback-routing mistakes early in the docs and skill so agents make fewer wrong assumptions during workflow migrations.

Ploop-Iter: 15

* docs: tighten cost model deep dives

Clarify the cost-model narrative so launch materials make source-verifiable
claims about suspension, wake-up paths, and polling behavior.

This keeps the GA messaging aligned with the runtime's actual control
flow and avoids overclaiming where the implementation has narrower
semantics than the original copy suggested.

Ploop-Iter: 11

* docs(skills): tighten resume routing guidance

Keep the migration skill entrypoint small so agents load the routing contract only when the source actually pauses for external resume. Clarify the public webhook docs around the default callback flow to reduce accidental use of lower-level runtime APIs.\n\nPloop-Iter: 16

* docs: tighten deep-dive runtime claims

Align the launch materials with the current runtime semantics so the
cost-model and execution-model narrative stays defensible against the
actual implementation.

This keeps the GA campaign focused on claims we can support directly from
source, especially around suspension, re-enqueue behavior, and the
difference between orchestration compute and client-side polling helpers.

Ploop-Iter: 12

* docs: correct cost model deep dive claims

Align the cost-model launch content with the runtime's actual suspension and re-entry mechanics so GA messaging does not overstate identical-cost waits or imply residency that the queue-based engine does not have.

This keeps the public explanation consistent with source-backed behavior around timed wake-ups, explicit workflow re-queue after step completion, and the distinction between idle worker residency and boundary I/O.

Ploop-Iter: 13

* chore: remove non-cookbook files from cookbook branch

Remove deep-dive articles, migration guides/skill, vercel-toolbar skill,
workflow-skills test fixtures, and misc artifacts that belong in separate
branches (deep-dives, migration-guides). Revert create-webhook.mdx,
getting-started/meta.json, and code-transform.mdx to main versions.

* docs: address toolbar feedback on cookbook pages

Address Vercel toolbar comments from Nathan Rajlich, Peter Wielander, Pranay Prakash, and Karthik Kalyanaraman on the cookbook branch.

In saga.mdx, remove the unnecessary `if (!(error instanceof FatalError)) throw error;` guard in the catch block — compensations should always unwind regardless of error type. Replace the `while/pop()!()` loop with a cleaner `for...of reverse()` to avoid the non-null assertion.

In ai-sdk.mdx, split the "Using Different Providers" section into two subsections: "Vercel Gateway (string model IDs)" clarifying that all string model IDs route through Gateway, and "Direct Provider Access" showing how to import from provider packages like `@workflow/ai/openai` to bypass Gateway. Change the "Tool Functions as Steps" section to "Tool Functions with Steps" and reword to explain that tool execute functions can optionally include steps via "use step" but don't have to — when they aren't steps, they run in workflow context and can modify workflow state directly.

In sandbox.mdx, rewrite the page to reflect that `@vercel/sandbox` now has first-class Workflow SDK support. Replace all `declare function` stubs and `// TODO` placeholders with real `import { Sandbox } from "@vercel/sandbox"`. Remove the four separate "use step" wrapper functions (provisionSandbox, runCommand, teardownSandbox, saveSandboxSnapshot) and show direct `Sandbox.create()`, `sandbox.runCommand()`, and `sandbox.destroy()` calls in the workflow function since these implicitly run as steps. Simplify the agent tool example to use inline execute functions that call Sandbox methods directly with an `activeSandbox` variable for workflow state.

Across all cookbook files, replace "Workflow DevKit" with "Workflow SDK" (8 instances in 5 files: publishing-libraries.mdx, secure-credentials.mdx, ai-sdk.mdx, chat-sdk.mdx, sandbox.mdx).

* docs: simplify cookbook index to plain MDX listing

Replace the interactive CookbookExplorer (726-line decision tree + browse
component) with a simple MDX page that lists recipes grouped by category
with linked titles and descriptions. Remove v1-v5 design variations and
trim cookbook-tree.ts to sidebar-only metadata.

* fix type checks

---------

Co-authored-by: Karthik Kalyanaraman <karthik.kalyanaraman@vercel.com>
* docs: add workflow migration guides and migration skill

Create migration guides for AWS Step Functions, Inngest, and Temporal under
docs/content/docs/getting-started/. Each guide provides side-by-side code
comparisons and a realistic order-processing saga example.

Add skills/migrating-to-vercel-workflow/ with SKILL.md, reference docs for
each source platform (aws-step-functions, inngest, temporal), shared patterns,
resume routing, runtime targets, and 5 eval scenarios.

Update create-webhook API reference with webhook resume choice clarifications.
Update getting-started meta.json to include migration guide navigation entries.

* In PR #1584 (migration-guides branch), make two changes to the migration guides:

1. Move migration guides to a top-level "Migration Guides" nav section:
   - Create docs/content/docs/migration-guides/ directory
   - Move the 3 migrating-from-*.mdx files from getting-started/ into migration-guides/
   - Create migration-guides/meta.json with title "Migration Guides" listing temporal, inngest, aws-step-functions
   - Add "migration-guides" between "errors" and "api-reference" in docs/content/docs/meta.json
   - Remove the 3 migration entries from getting-started/meta.json

2. Replace all "Vercel Workflow" language with "Workflow SDK" across docs and skills:
   - In all 3 MDX migration guides: replace "Vercel Workflow" with "the Workflow SDK" or "Workflow SDK" in frontmatter, headings, table headers, and body text
   - Replace "shipping on Vercel" with neutral phrasing, "Vercel-managed execution" with "managed execution", "Vercel's infrastructure" with neutral phrasing
   - Replace Vercel-specific pricing paragraphs with generic "Efficient resource usage" bullet
   - Replace "Deploy to Vercel first..." checklist items with neutral deployment guidance
   - Keep vercel-world prerequisite links (real package name)
   - Rename skills/migrating-to-vercel-workflow/ to skills/migrating-to-workflow-sdk/
   - Update all skill SKILL.md, evals/, and references/ files to replace "Vercel Workflow" with "Workflow SDK"
   - Update runtime-targets.md section headers from "Non-Vercel" to "Self-hosted"

* fix type checks

---------

Co-authored-by: Karthik Kalyanaraman <karthik.kalyanaraman@vercel.com>
)

* fix(next): resolve next/package.json from working directory first

In npm workspaces monorepos, `@workflow/next` can be hoisted to the root
`node_modules/` while `next` stays in a workspace's local `node_modules/`.
The eager `require('next/package.json')` on the fallback path resolved
relative to `@workflow/next`'s own location, failing before the correct
working-directory-relative resolution could run.

Restructure `resolveNextVersion()` to try the working directory path first,
fall back to the package-relative path second, and wrap both in separate
try/catch blocks so neither can crash the process.

Closes #1680

* fix(next): capture resolution errors and include workingDir in error message

Address review feedback: capture caught errors from both resolution
attempts and attach them via `cause` on the final thrown error. Include
the working directory in the error message to aid debugging in monorepo
and CI environments.
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
@vercel
Copy link
Copy Markdown
Contributor

vercel bot commented Apr 13, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
example-nextjs-workflow-turbopack Ready Ready Preview, Comment Apr 13, 2026 7:08pm
example-nextjs-workflow-webpack Ready Ready Preview, Comment Apr 13, 2026 7:08pm
example-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-astro-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-express-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-fastify-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-hono-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-nitro-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-nuxt-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-sveltekit-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workbench-vite-workflow Ready Ready Preview, Comment Apr 13, 2026 7:08pm
workflow-docs Ready Ready Preview, Comment, Open in v0 Apr 13, 2026 7:08pm
workflow-swc-playground Ready Ready Preview, Comment Apr 13, 2026 7:08pm

@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Apr 13, 2026

🦋 Changeset detected

Latest commit: 5c048b0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
Name Type
@workflow/next Patch
workflow Patch
nextjs-eager Patch
@workflow/ai Patch
@workflow/world-testing Patch
@workflow/core Patch
@workflow/builders Patch
@workflow/cli Patch
@workflow/nitro Patch
@workflow/vitest Patch
@workflow/web-shared Patch
@workflow/astro Patch
@workflow/nest Patch
@workflow/rollup Patch
@workflow/sveltekit Patch
@workflow/vite Patch
@workflow/nuxt Patch

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

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 13, 2026

🧪 E2E Test Results

Some tests failed

Summary

Passed Failed Skipped Total
❌ ▲ Vercel Production 922 1 67 990
✅ 💻 Local Development 1037 0 223 1260
✅ 📦 Local Production 1037 0 223 1260
✅ 🐘 Local Postgres 1037 0 223 1260
✅ 🪟 Windows 82 0 8 90
❌ 🌍 Community Worlds 133 74 24 231
✅ 📋 Other 228 0 42 270
Total 4476 75 810 5361

❌ Failed Tests

▲ Vercel Production (1 failed)

nextjs-turbopack (1 failed):

  • error handling retry behavior FatalError fails immediately without retries
🌍 Community Worlds (74 failed)

mongodb (7 failed):

  • hookWorkflow is not resumable via public webhook endpoint | wrun_01KP43X18CZZKQR7CKPRG6T3WA
  • webhookWorkflow | wrun_01KP43XBHXM2940ZVKQQZN194H
  • fetchWorkflow | wrun_01KP4411DS1PGBKFP1PYMFXZHN
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously | wrun_01KP4450F8SQQAAXB5D08CJAW5
  • health check (queue-based) - workflow and step endpoints respond to health check messages
  • health check (CLI) - workflow health command reports healthy endpoints
  • resilient start: addTenWorkflow completes when run_created returns 500 | wrun_01KP44B4368DNXBT5B56EQDGK7

redis (7 failed):

  • hookWorkflow is not resumable via public webhook endpoint | wrun_01KP43X18CZZKQR7CKPRG6T3WA
  • webhookWorkflow | wrun_01KP43XBHXM2940ZVKQQZN194H
  • fetchWorkflow | wrun_01KP4411DS1PGBKFP1PYMFXZHN
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously | wrun_01KP4450F8SQQAAXB5D08CJAW5
  • health check (queue-based) - workflow and step endpoints respond to health check messages
  • health check (CLI) - workflow health command reports healthy endpoints
  • resilient start: addTenWorkflow completes when run_created returns 500 | wrun_01KP44B4368DNXBT5B56EQDGK7

turso (60 failed):

  • addTenWorkflow | wrun_01KP43VXZEBN6Y6Y6QFWHE2A9A
  • addTenWorkflow | wrun_01KP43VXZEBN6Y6Y6QFWHE2A9A
  • wellKnownAgentWorkflow (.well-known/agent) | wrun_01KP43Y14DF8D7EA2XQBJ4X75C
  • should work with react rendering in step
  • promiseAllWorkflow | wrun_01KP43W422KYE00TKNBSD068BR
  • promiseRaceWorkflow | wrun_01KP43W8H40QCN0W6H47WKMNYG
  • promiseAnyWorkflow | wrun_01KP43WAHKEH5T2B60XRSP0M8G
  • importedStepOnlyWorkflow | wrun_01KP43YDG9DPQDBK4TKJGSFKZT
  • hookWorkflow | wrun_01KP43WP6ACDARS0WDSX2TKB6T
  • hookWorkflow is not resumable via public webhook endpoint | wrun_01KP43X18CZZKQR7CKPRG6T3WA
  • webhookWorkflow | wrun_01KP43XBHXM2940ZVKQQZN194H
  • sleepingWorkflow | wrun_01KP43XKCA1YQX88GRKSWKRDGR
  • parallelSleepWorkflow | wrun_01KP43XZP7S637Y4ZA8DAY2BCF
  • nullByteWorkflow | wrun_01KP43Y3XRDZX7R8XWEN3Q6V09
  • workflowAndStepMetadataWorkflow | wrun_01KP43Y62WMWGMA7S4A89AM14Y
  • fetchWorkflow | wrun_01KP4411DS1PGBKFP1PYMFXZHN
  • promiseRaceStressTestWorkflow | wrun_01KP4414KJD0K22WJ0QTVHE1AN
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • error handling not registered WorkflowNotRegisteredError fails the run when workflow does not exist
  • error handling not registered StepNotRegisteredError fails the step but workflow can catch it
  • error handling not registered StepNotRegisteredError fails the run when not caught in workflow
  • hookCleanupTestWorkflow - hook token reuse after workflow completion | wrun_01KP444ESR96G5XCP8QH1M6WCV
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously | wrun_01KP4450F8SQQAAXB5D08CJAW5
  • hookDisposeTestWorkflow - hook token reuse after explicit disposal while workflow still running | wrun_01KP445MXD64VC3Q2QYTRT58ZY
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars) | wrun_01KP446725K9EBNNA1GWEDBQ4M
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument | wrun_01KP446EK27QK8NNS07FM2JFKN
  • closureVariableWorkflow - nested step functions with closure variables | wrun_01KP446KC9VV414825C2N27WQQ
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step | wrun_01KP446NA8EYJQ8KBQTVHRYCMT
  • runClassSerializationWorkflow - Run instances serialize across workflow/step boundaries | wrun_01KP446Z5TXPX9QWJA5SAJMQ8H
  • health check (queue-based) - workflow and step endpoints respond to health check messages
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly | wrun_01KP447BPNZYQG7W2Q19CB17GF
  • Calculator.calculate - static workflow method using static step methods from another class | wrun_01KP447GFAJ8XNN0BQNHY384GC
  • AllInOneService.processNumber - static workflow method using sibling static step methods | wrun_01KP447PBWX2A44AZPH2RV4599
  • ChainableService.processWithThis - static step methods using this to reference the class | wrun_01KP447WHPD8MSHRF095S8PED2
  • thisSerializationWorkflow - step function invoked with .call() and .apply() | wrun_01KP4482JPXMQZDX2MA5PJ9QCD
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE | wrun_01KP4488FDTQ3M33BNPHGNKAXF
  • instanceMethodStepWorkflow - instance methods with "use step" directive | wrun_01KP448EGH53HEMCR9RB5AM63S
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context | wrun_01KP448RS2FV4W8DH4Q0WND4FK
  • stepFunctionAsStartArgWorkflow - step function reference passed as start() argument | wrun_01KP448ZS4TMQ0EQ4PQSNAP6K8
  • cancelRun - cancelling a running workflow | wrun_01KP4498CHSPS9X4822NHKKH5P
  • cancelRun via CLI - cancelling a running workflow | wrun_01KP449GZWQAJHFS894AAAGBAM
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router
  • hookWithSleepWorkflow - hook payloads delivered correctly with concurrent sleep | wrun_01KP449VXFM61B2YXKP0DEMBXW
  • sleepInLoopWorkflow - sleep inside loop with steps actually delays each iteration | wrun_01KP44AEXWQ7VQW7VNEE38NH1Q
  • sleepWithSequentialStepsWorkflow - sequential steps work with concurrent sleep (control) | wrun_01KP44AT0B309HGQEJWEM8FD8C
  • importMetaUrlWorkflow - import.meta.url is available in step bundles | wrun_01KP44AZZBXD31M6P7DZGAHRWD
  • metadataFromHelperWorkflow - getWorkflowMetadata/getStepMetadata work from module-level helper (#1577) | wrun_01KP44B223MFB3G2728F76SJSZ
  • resilient start: addTenWorkflow completes when run_created returns 500 | wrun_01KP44B4368DNXBT5B56EQDGK7
  • getterStepWorkflow - getter functions with "use step" directive | wrun_01KP44B8E9HF85B4ZS5B86B5CY

Details by Category

❌ ▲ Vercel Production
App Passed Failed Skipped
✅ astro 83 0 7
✅ example 83 0 7
✅ express 83 0 7
✅ fastify 83 0 7
✅ hono 83 0 7
❌ nextjs-turbopack 87 1 2
✅ nextjs-webpack 88 0 2
✅ nitro 83 0 7
✅ nuxt 83 0 7
✅ sveltekit 83 0 7
✅ vite 83 0 7
✅ 💻 Local Development
App Passed Failed Skipped
✅ astro-stable 76 0 14
✅ express-stable 76 0 14
✅ fastify-stable 76 0 14
✅ hono-stable 76 0 14
✅ nextjs-eager-canary 60 0 30
✅ nextjs-eager-stable 79 0 11
✅ nextjs-turbopack-canary 63 0 27
✅ nextjs-turbopack-stable 82 0 8
✅ nextjs-webpack-canary 63 0 27
✅ nextjs-webpack-stable 82 0 8
✅ nitro-stable 76 0 14
✅ nuxt-stable 76 0 14
✅ sveltekit-stable 76 0 14
✅ vite-stable 76 0 14
✅ 📦 Local Production
App Passed Failed Skipped
✅ astro-stable 76 0 14
✅ express-stable 76 0 14
✅ fastify-stable 76 0 14
✅ hono-stable 76 0 14
✅ nextjs-eager-canary 60 0 30
✅ nextjs-eager-stable 79 0 11
✅ nextjs-turbopack-canary 63 0 27
✅ nextjs-turbopack-stable 82 0 8
✅ nextjs-webpack-canary 63 0 27
✅ nextjs-webpack-stable 82 0 8
✅ nitro-stable 76 0 14
✅ nuxt-stable 76 0 14
✅ sveltekit-stable 76 0 14
✅ vite-stable 76 0 14
✅ 🐘 Local Postgres
App Passed Failed Skipped
✅ astro-stable 76 0 14
✅ express-stable 76 0 14
✅ fastify-stable 76 0 14
✅ hono-stable 76 0 14
✅ nextjs-eager-canary 60 0 30
✅ nextjs-eager-stable 79 0 11
✅ nextjs-turbopack-canary 63 0 27
✅ nextjs-turbopack-stable 82 0 8
✅ nextjs-webpack-canary 63 0 27
✅ nextjs-webpack-stable 82 0 8
✅ nitro-stable 76 0 14
✅ nuxt-stable 76 0 14
✅ sveltekit-stable 76 0 14
✅ vite-stable 76 0 14
✅ 🪟 Windows
App Passed Failed Skipped
✅ nextjs-turbopack 82 0 8
❌ 🌍 Community Worlds
App Passed Failed Skipped
✅ mongodb-dev 6 0 0
❌ mongodb 56 7 8
✅ redis-dev 6 0 0
❌ redis 56 7 8
✅ turso-dev 6 0 0
❌ turso 3 60 8
✅ 📋 Other
App Passed Failed Skipped
✅ e2e-local-dev-nest-stable 76 0 14
✅ e2e-local-postgres-nest-stable 76 0 14
✅ e2e-local-prod-nest-stable 76 0 14

📋 View full workflow run


Some E2E test jobs failed:

  • Vercel Prod: failure
  • Local Dev: success
  • Local Prod: success
  • Local Postgres: success
  • Windows: success

Check the workflow run for details.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 13, 2026

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 0.041s (+13.2% 🔺) 1.006s (~) 0.965s 10 1.00x
💻 Local Nitro 0.042s (+1.0%) 1.005s (~) 0.963s 10 1.02x
🐘 Postgres Nitro 0.061s (-9.0% 🟢) 1.012s (~) 0.951s 10 1.48x
🐘 Postgres Express 0.062s (+7.1% 🔺) 1.010s (~) 0.948s 10 1.50x
🐘 Postgres Next.js (Turbopack) 0.062s (+26.1% 🔺) 1.011s (~) 0.949s 10 1.50x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 1 step

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Nitro 1.127s (~) 2.006s (~) 0.878s 10 1.00x
💻 Local Express 1.134s (+3.4%) 2.006s (~) 0.872s 10 1.01x
🐘 Postgres Nitro 1.135s (-1.3%) 2.009s (~) 0.874s 10 1.01x
🐘 Postgres Next.js (Turbopack) 1.143s (+1.8%) 2.010s (~) 0.867s 10 1.01x
🐘 Postgres Express 1.147s (~) 2.010s (~) 0.863s 10 1.02x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 10 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Next.js (Turbopack) 10.898s (+1.0%) 11.020s (~) 0.122s 3 1.00x
🐘 Postgres Nitro 10.900s (~) 11.024s (~) 0.124s 3 1.00x
💻 Local Express 10.937s (+2.8%) 11.024s (~) 0.087s 3 1.00x
💻 Local Nitro 10.940s (~) 11.023s (~) 0.084s 3 1.00x
🐘 Postgres Express 10.952s (+0.7%) 11.016s (~) 0.063s 3 1.00x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 25 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 14.511s (~) 15.023s (~) 0.511s 4 1.00x
🐘 Postgres Express 14.549s (~) 15.019s (~) 0.471s 4 1.00x
🐘 Postgres Next.js (Turbopack) 14.632s (+3.3%) 15.024s (~) 0.393s 4 1.01x
💻 Local Nitro 14.974s (~) 15.030s (~) 0.056s 4 1.03x
💻 Local Express 14.988s (+5.2% 🔺) 15.030s (~) 0.042s 4 1.03x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 50 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 13.917s (-1.5%) 14.166s (-3.9%) 0.249s 7 1.00x
🐘 Postgres Express 13.942s (~) 14.306s (~) 0.364s 7 1.00x
🐘 Postgres Next.js (Turbopack) 14.061s (+4.8%) 14.596s (+3.0%) 0.535s 7 1.01x
💻 Local Nitro 16.644s (-0.6%) 17.032s (~) 0.388s 6 1.20x
💻 Local Express 16.663s (+10.8% 🔺) 17.031s (+9.7% 🔺) 0.368s 6 1.20x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Promise.all with 10 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Next.js (Turbopack) 1.237s (+4.3%) 2.009s (~) 0.772s 15 1.00x
🐘 Postgres Express 1.261s (-1.2%) 2.009s (~) 0.749s 15 1.02x
🐘 Postgres Nitro 1.267s (-1.1%) 2.009s (~) 0.742s 15 1.02x
💻 Local Express 1.547s (+7.3% 🔺) 2.006s (~) 0.459s 15 1.25x
💻 Local Nitro 1.551s (+1.9%) 2.006s (~) 0.455s 15 1.25x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Promise.all with 25 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 2.318s (-1.3%) 3.010s (~) 0.692s 10 1.00x
🐘 Postgres Nitro 2.318s (-1.6%) 3.008s (~) 0.690s 10 1.00x
🐘 Postgres Next.js (Turbopack) 2.433s (-0.6%) 3.010s (~) 0.577s 10 1.05x
💻 Local Express 3.022s (+17.2% 🔺) 3.455s (+14.9% 🔺) 0.432s 9 1.30x
💻 Local Nitro 3.069s (+3.5%) 3.565s (-5.2% 🟢) 0.496s 9 1.32x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Promise.all with 50 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 3.433s (-1.6%) 4.010s (~) 0.577s 8 1.00x
🐘 Postgres Express 3.451s (-1.2%) 4.009s (~) 0.558s 8 1.01x
🐘 Postgres Next.js (Turbopack) 3.733s (+3.7%) 4.012s (~) 0.279s 8 1.09x
💻 Local Nitro 8.341s (~) 9.019s (~) 0.678s 4 2.43x
💻 Local Express 8.649s (+28.7% 🔺) 9.271s (+32.1% 🔺) 0.622s 4 2.52x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Promise.race with 10 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Next.js (Turbopack) 1.230s (+3.3%) 2.008s (~) 0.779s 15 1.00x
🐘 Postgres Nitro 1.261s (-0.5%) 2.009s (~) 0.748s 15 1.03x
🐘 Postgres Express 1.266s (~) 2.009s (~) 0.743s 15 1.03x
💻 Local Nitro 1.596s (+4.7%) 2.073s (+3.4%) 0.477s 15 1.30x
💻 Local Express 1.927s (+31.4% 🔺) 2.364s (+17.9% 🔺) 0.437s 14 1.57x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Promise.race with 25 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 2.312s (-2.2%) 3.010s (~) 0.698s 10 1.00x
🐘 Postgres Express 2.325s (-1.6%) 3.010s (~) 0.685s 10 1.01x
🐘 Postgres Next.js (Turbopack) 2.413s (+2.0%) 3.010s (~) 0.597s 10 1.04x
💻 Local Nitro 2.979s (-3.8%) 3.676s (-8.3% 🟢) 0.697s 9 1.29x
💻 Local Express 3.035s (+2.1%) 3.760s (+12.5% 🔺) 0.725s 8 1.31x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Promise.race with 50 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 3.458s (-1.1%) 4.012s (~) 0.554s 8 1.00x
🐘 Postgres Express 3.466s (-1.2%) 4.011s (~) 0.545s 8 1.00x
🐘 Postgres Next.js (Turbopack) 3.690s (+3.1%) 4.013s (~) 0.323s 8 1.07x
💻 Local Express 8.720s (+8.4% 🔺) 9.023s (+2.9%) 0.304s 4 2.52x
💻 Local Nitro 8.750s (-6.3% 🟢) 9.022s (-10.0% 🟢) 0.272s 4 2.53x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 10 sequential data payload steps (10KB)

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 0.804s (-4.0%) 1.006s (~) 0.202s 60 1.00x
🐘 Postgres Next.js (Turbopack) 0.816s (+27.2% 🔺) 1.023s (+1.7%) 0.208s 59 1.01x
🐘 Postgres Express 0.826s (-0.9%) 1.023s (+1.7%) 0.197s 59 1.03x
💻 Local Express 0.998s (+42.5% 🔺) 1.303s (+29.7% 🔺) 0.305s 47 1.24x
💻 Local Nitro 0.999s (+1.0%) 1.400s (+11.6% 🔺) 0.401s 43 1.24x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 25 sequential data payload steps (10KB)

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 1.905s (-1.7%) 2.100s (-6.7% 🟢) 0.195s 43 1.00x
🐘 Postgres Express 1.942s (-1.1%) 2.123s (-4.7%) 0.181s 43 1.02x
🐘 Postgres Next.js (Turbopack) 1.995s (+21.3% 🔺) 2.378s (+17.2% 🔺) 0.383s 38 1.05x
💻 Local Nitro 3.025s (~) 3.649s (+1.8%) 0.624s 25 1.59x
💻 Local Express 3.061s (+25.4% 🔺) 3.923s (+23.3% 🔺) 0.862s 23 1.61x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 50 sequential data payload steps (10KB)

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 3.869s (-0.6%) 4.076s (-1.7%) 0.207s 30 1.00x
🐘 Postgres Express 3.954s (-1.7%) 4.252s (-4.6%) 0.299s 29 1.02x
🐘 Postgres Next.js (Turbopack) 4.034s (+26.4% 🔺) 4.455s (+12.0% 🔺) 0.421s 27 1.04x
💻 Local Nitro 9.169s (-0.8%) 9.941s (-0.8%) 0.772s 13 2.37x
💻 Local Express 9.173s (+25.6% 🔺) 9.710s (+22.1% 🔺) 0.537s 13 2.37x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 10 concurrent data payload steps (10KB)

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Next.js (Turbopack) 0.257s (+20.7% 🔺) 1.007s (~) 0.750s 60 1.00x
🐘 Postgres Express 0.277s (-1.9%) 1.007s (~) 0.730s 60 1.08x
🐘 Postgres Nitro 0.279s (+1.2%) 1.007s (~) 0.728s 60 1.08x
💻 Local Express 0.577s (-0.9%) 1.004s (~) 0.427s 60 2.25x
💻 Local Nitro 0.580s (~) 1.004s (~) 0.425s 60 2.26x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 25 concurrent data payload steps (10KB)

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 0.481s (-4.5%) 1.006s (~) 0.526s 90 1.00x
🐘 Postgres Nitro 0.487s (-2.5%) 1.007s (~) 0.520s 90 1.01x
🐘 Postgres Next.js (Turbopack) 0.503s (+19.8% 🔺) 1.007s (~) 0.503s 90 1.05x
💻 Local Express 2.488s (+3.9%) 3.008s (~) 0.521s 30 5.18x
💻 Local Nitro 2.641s (+6.7% 🔺) 3.009s (~) 0.368s 30 5.50x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
workflow with 50 concurrent data payload steps (10KB)

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 0.777s (-1.6%) 1.007s (~) 0.230s 120 1.00x
🐘 Postgres Nitro 0.788s (+0.7%) 1.009s (~) 0.220s 119 1.01x
🐘 Postgres Next.js (Turbopack) 0.831s (+25.3% 🔺) 1.008s (~) 0.177s 119 1.07x
💻 Local Express 10.971s (+9.6% 🔺) 11.572s (+8.2% 🔺) 0.601s 11 14.12x
💻 Local Nitro 11.303s (+1.8%) 11.939s (+0.8%) 0.636s 11 14.54x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
Stream Benchmarks (includes TTFB metrics)
workflow with stream

💻 Local Development

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 0.199s (+42.3% 🔺) 1.005s (~) 0.012s (+24.5% 🔺) 1.018s (~) 0.819s 10 1.00x
💻 Local Nitro 0.204s (+0.5%) 1.004s (~) 0.012s (-2.5%) 1.018s (~) 0.814s 10 1.03x
🐘 Postgres Next.js (Turbopack) 0.204s (+23.4% 🔺) 1.001s (~) 0.002s (+80.0% 🔺) 1.011s (~) 0.806s 10 1.03x
🐘 Postgres Express 0.207s (~) 0.998s (~) 0.001s (-7.7% 🟢) 1.009s (~) 0.802s 10 1.04x
🐘 Postgres Nitro 0.210s (-1.6%) 0.992s (-0.5%) 0.001s (~) 1.009s (~) 0.799s 10 1.05x
💻 Local Next.js (Turbopack) ⚠️ missing - - - - -
stream pipeline with 5 transform steps (1MB)

💻 Local Development

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 0.610s (~) 1.005s (~) 0.004s (-21.0% 🟢) 1.022s (~) 0.412s 59 1.00x
🐘 Postgres Nitro 0.614s (~) 1.005s (~) 0.004s (+10.0% 🔺) 1.023s (~) 0.409s 59 1.01x
🐘 Postgres Next.js (Turbopack) 0.656s (+13.7% 🔺) 1.026s (+1.8%) 0.004s (+15.5% 🔺) 1.051s (+2.8%) 0.395s 59 1.08x
💻 Local Express 0.924s (+65.6% 🔺) 1.012s (~) 0.010s (+12.2% 🔺) 1.228s (+20.2% 🔺) 0.304s 49 1.52x
💻 Local Nitro 1.074s (+47.8% 🔺) 1.011s (~) 0.010s (-2.1%) 1.364s (+33.3% 🔺) 0.290s 44 1.76x
💻 Local Next.js (Turbopack) ⚠️ missing - - - - -
10 parallel streams (1MB each)

💻 Local Development

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 0.946s (~) 1.168s (~) 0.000s (-67.3% 🟢) 1.184s (~) 0.238s 52 1.00x
🐘 Postgres Nitro 0.976s (~) 1.214s (+1.8%) 0.000s (-49.0% 🟢) 1.243s (+2.1%) 0.267s 50 1.03x
🐘 Postgres Next.js (Turbopack) 0.979s (+5.2% 🔺) 1.278s (+15.0% 🔺) 0.000s (-23.4% 🟢) 1.285s (+14.8% 🔺) 0.307s 47 1.03x
💻 Local Express 1.195s (+4.8%) 2.018s (~) 0.000s (-37.5% 🟢) 2.020s (~) 0.825s 30 1.26x
💻 Local Nitro 1.234s (~) 2.019s (~) 0.000s (-12.5% 🟢) 2.021s (~) 0.787s 30 1.31x
💻 Local Next.js (Turbopack) ⚠️ missing - - - - -
fan-out fan-in 10 streams (1MB each)

💻 Local Development

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 1.706s (-4.1%) 2.104s (-1.5%) 0.000s (+Infinity% 🔺) 2.113s (-1.6%) 0.407s 29 1.00x
🐘 Postgres Nitro 1.769s (~) 2.102s (~) 0.000s (~) 2.113s (~) 0.344s 29 1.04x
🐘 Postgres Next.js (Turbopack) 1.946s (+3.5%) 2.182s (-3.5%) 0.000s (+Infinity% 🔺) 2.190s (-3.5%) 0.243s 28 1.14x
💻 Local Express 3.367s (+2.8%) 4.032s (+3.2%) 0.000s (-32.1% 🟢) 4.034s (+3.2%) 0.667s 15 1.97x
💻 Local Nitro 3.607s (+3.0%) 4.096s (~) 0.001s (-35.7% 🟢) 4.099s (~) 0.492s 15 2.11x
💻 Local Next.js (Turbopack) ⚠️ missing - - - - -

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World 🥇 Fastest Framework Wins
💻 Local Express 13/21
🐘 Postgres Nitro 10/21
Fastest World by Framework

Winner determined by most benchmark wins

Framework 🥇 Fastest World Wins
Express 🐘 Postgres 17/21
Next.js (Turbopack) 🐘 Postgres 21/21
Nitro 🐘 Postgres 18/21
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run


Some benchmark jobs failed:

  • Local: cancelled
  • Postgres: success
  • Vercel: failure

Check the workflow run for details.

The dev HMR tests for deferred step file copies require lazyDiscovery
to be enabled. Add a config override so nextjs-eager correctly skips
these tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@VaguelySerious VaguelySerious marked this pull request as ready for review April 13, 2026 21:29
@VaguelySerious VaguelySerious requested review from a team and ijjk as code owners April 13, 2026 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants