Skip to content

Fix 12 documentation accuracy issues across API reference, foundations, and AI docs#1200

Closed
johnlindquist wants to merge 5 commits into
mainfrom
worktree-swift-jumping-pizza
Closed

Fix 12 documentation accuracy issues across API reference, foundations, and AI docs#1200
johnlindquist wants to merge 5 commits into
mainfrom
worktree-swift-jumping-pizza

Conversation

@johnlindquist
Copy link
Copy Markdown
Contributor

Summary

Fixes validated documentation issues found during a comprehensive docs audit:

  • API reference: Fix nonexistent world.runs.cancel() in getWorld examples — replaced with cancelRun() from @workflow/core/runtime
  • Streaming guide: Fix import path mismatch (simple vs simple-streaming) and replace nonexistent run.result() with run.returnValue
  • World/Streamer interfaces: Add missing close?() and getEncryptionKeyForRun?() to World, fix runId type from string | Promise<string> to string in Streamer, add missing writeToStreamMulti? method
  • Deploying docs: Fix wrong Postgres world package name (@workflow-worlds/postgres@workflow/world-postgres)
  • AI docs: Fix tools naming mismatch (tools vs flightBookingTools), remove unused getWritable import, fix missing || operator, add missing RetryableError import, fix broken highlight annotation
  • Misc: Fix [!code highlight} typo, correct "Vite root directory" → "Astro project root directory", fix inaccurate npx "install globally" claim, remove fetch from Node.js core modules list

Test plan

  • Verify docs build succeeds
  • Spot-check corrected code examples compile against actual workflow exports
  • Verify getWorld cancel example uses correct cancelRun API
  • Verify World/Streamer interfaces match packages/world/src/interfaces.ts

Update docs examples that referenced outdated or incorrect APIs.
This fixes cancellation usage in get-world, stream import path and run return access in streaming, clarifies stream wording in starting-workflows, and removes fetch from Node.js core module examples.

Verified: node -e '...docs snippet verification passed' (requested old/new snippets checked in 4 files)
How to test: run the same node assertion command from repo root to confirm snippets.
Swarm-Agent: codex-core-docs
Correct World interface docs to include close() and getEncryptionKeyForRun() overloads, and clarify their runtime behavior.
Update Streamer runId types to string, add writeToStreamMulti(), and document it as an optional batching optimization.
Also fix package references from @workflow-worlds/postgres to @workflow/world-postgres.

Verified: pnpm biome check docs/content/docs/deploying/building-a-world.mdx docs/content/docs/deploying/index.mdx (fails because Biome config ignores *.mdx paths)
Verified: node <<'NODE' ... scoped assertions on docs/content/docs/deploying/building-a-world.mdx and docs/content/docs/deploying/index.mdx (pass)
Swarm-Agent: codex-world-interface
Align code examples across AI docs by renaming the tools export, fixing import snippets, restoring a missing logical OR, adding missing RetryableError import context, and repairing a broken highlight annotation.

Verified: git diff --check -- docs/content/docs/ai/index.mdx docs/content/docs/ai/sleep-and-delays.mdx docs/content/docs/ai/resumable-streams.mdx
Verified: set -euo pipefail; rg -n "export const flightBookingTools = \\{" docs/content/docs/ai/index.mdx; rg -n "import \\{ flightBookingTools \\} from \"@/ai/tools\";" docs/content/docs/ai/index.mdx; rg -n "import \\{ sleep \\} from \"workflow\";" docs/content/docs/ai/sleep-and-delays.mdx; rg -n "tool-checkBaggageAllowance\" \\|\\|" docs/content/docs/ai/sleep-and-delays.mdx; rg -n "part.type === \"tool-sleep\"" docs/content/docs/ai/sleep-and-delays.mdx; rg -n "import \\{ RetryableError \\} from \"workflow\";" docs/content/docs/ai/sleep-and-delays.mdx; rg -n "headers: \\{ // \\[!code highlight\\]" docs/content/docs/ai/resumable-streams.mdx
Swarm-Agent: codex-ai-docs
Update three docs files to fix a malformed code-highlight annotation,\nclarify Astro directory wording, and correct npx behavior wording.\n\nVerified: set -e; rg assertions for old/new strings in all 3 files (pass)\nVerified: git diff --check -- docs/content/docs/errors/start-invalid-workflow-function.mdx docs/content/docs/getting-started/astro.mdx docs/content/docs/observability/index.mdx (pass)\nVerified: npx -y prettier@3 --check docs/content/docs/errors/start-invalid-workflow-function.mdx docs/content/docs/getting-started/astro.mdx docs/content/docs/observability/index.mdx (fails: pre-existing formatting style mismatch in docs)\nSwarm-Agent: codex-misc-fixes
@johnlindquist johnlindquist requested a review from a team as a code owner February 26, 2026 04:23
@vercel
Copy link
Copy Markdown
Contributor

vercel Bot commented Feb 26, 2026

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Feb 26, 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.025s (-22.3% 🟢) 1.005s (~) 0.979s 10 1.00x
💻 Local Nitro 0.033s (+2.8%) 1.005s (~) 0.972s 10 1.31x
🐘 Postgres Nitro 0.054s (-4.1%) 1.010s (~) 0.956s 10 2.13x
🐘 Postgres Express 0.056s (+4.3%) 1.010s (~) 0.955s 10 2.19x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 0.410s (-23.3% 🟢) 1.731s (-4.6%) 1.321s 10 1.00x
▲ Vercel Next.js (Turbopack) 0.458s (-19.1% 🟢) 1.907s (-4.3%) 1.449s 10 1.12x
▲ Vercel Express 0.458s (-28.0% 🟢) 1.795s (-9.8% 🟢) 1.337s 10 1.12x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 1.072s (-3.3%) 2.005s (~) 0.933s 10 1.00x
💻 Local Nitro 1.112s (~) 2.005s (~) 0.893s 10 1.04x
🐘 Postgres Express 1.129s (-0.9%) 2.018s (~) 0.889s 10 1.05x
🐘 Postgres Nitro 1.131s (~) 2.011s (~) 0.880s 10 1.05x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 1.975s (+1.3%) 2.840s (-3.5%) 0.865s 10 1.00x
▲ Vercel Next.js (Turbopack) 2.077s (+6.8% 🔺) 3.167s (+2.5%) 1.090s 10 1.05x
▲ Vercel Express 2.145s (+1.7%) 3.042s (-8.5% 🟢) 0.897s 10 1.09x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 10 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 10.554s (-2.6%) 11.020s (~) 0.467s 3 1.00x
🐘 Postgres Nitro 10.841s (-0.5%) 11.042s (~) 0.201s 3 1.03x
💻 Local Nitro 10.861s (~) 11.022s (~) 0.160s 3 1.03x
🐘 Postgres Express 10.918s (~) 11.045s (~) 0.126s 3 1.03x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 16.812s (+5.2% 🔺) 17.864s (+5.6% 🔺) 1.052s 2 1.00x
▲ Vercel Express 16.985s (+1.1%) 17.783s (-0.9%) 0.797s 2 1.01x
▲ Vercel Next.js (Turbopack) 17.249s (+6.6% 🔺) 18.776s (+10.2% 🔺) 1.527s 2 1.03x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 25 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 26.763s (-2.6%) 27.049s (-3.6%) 0.286s 3 1.00x
🐘 Postgres Nitro 27.309s (~) 28.070s (~) 0.762s 3 1.02x
🐘 Postgres Express 27.319s (~) 28.069s (~) 0.750s 3 1.02x
💻 Local Nitro 27.587s (~) 28.053s (~) 0.466s 3 1.03x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Next.js (Turbopack) 44.431s (+2.3%) 45.959s (+2.8%) 1.527s 2 1.00x
▲ Vercel Express 44.937s (+5.1% 🔺) 46.273s (+4.8%) 1.336s 2 1.01x
▲ Vercel Nitro 45.338s (+6.5% 🔺) 45.967s (+6.0% 🔺) 0.629s 2 1.02x

🔍 Observability: Next.js (Turbopack) | Express | Nitro

workflow with 50 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 54.971s (~) 55.099s (~) 0.128s 2 1.00x
🐘 Postgres Nitro 55.087s (~) 55.607s (-0.9%) 0.521s 2 1.00x
💻 Local Express 55.663s (-2.7%) 56.093s (-3.5%) 0.430s 2 1.01x
💻 Local Nitro 57.379s (~) 58.105s (~) 0.726s 2 1.04x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Express 95.058s (+3.0%) 96.094s (+2.8%) 1.036s 1 1.00x
▲ Vercel Nitro 99.276s (+7.0% 🔺) 100.397s (+7.7% 🔺) 1.121s 1 1.04x
▲ Vercel Next.js (Turbopack) 100.990s (+0.7%) 102.638s (+1.3%) 1.648s 1 1.06x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 10 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 1.353s (-3.9%) 2.005s (~) 0.652s 15 1.00x
🐘 Postgres Express 1.366s (~) 2.011s (~) 0.646s 15 1.01x
🐘 Postgres Nitro 1.377s (+1.8%) 2.010s (~) 0.634s 15 1.02x
💻 Local Nitro 1.402s (-2.1%) 2.006s (~) 0.604s 15 1.04x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Express 2.150s (-4.7%) 2.950s (-19.8% 🟢) 0.800s 11 1.00x
▲ Vercel Nitro 2.204s (-13.9% 🟢) 3.002s (-14.0% 🟢) 0.798s 10 1.03x
▲ Vercel Next.js (Turbopack) 2.600s (+17.2% 🔺) 3.671s (+16.8% 🔺) 1.071s 9 1.21x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 2.009s (+3.6%) 2.600s (+5.1% 🔺) 0.591s 12 1.00x
🐘 Postgres Nitro 2.013s (+3.4%) 2.514s (~) 0.501s 12 1.00x
💻 Local Express 2.280s (-9.7% 🟢) 3.006s (~) 0.727s 10 1.13x
💻 Local Nitro 2.488s (-4.9%) 3.007s (~) 0.519s 10 1.24x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 2.693s (-15.9% 🟢) 3.365s (-32.8% 🟢) 0.671s 9 1.00x
▲ Vercel Next.js (Turbopack) 3.022s (-4.2%) 3.929s (-3.4%) 0.907s 8 1.12x
▲ Vercel Express 3.126s (+25.4% 🔺) 4.034s (+10.5% 🔺) 0.908s 8 1.16x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 50 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 3.627s (+6.1% 🔺) 4.266s (+5.8% 🔺) 0.639s 8 1.00x
🐘 Postgres Express 3.780s (+14.9% 🔺) 4.314s (+10.6% 🔺) 0.534s 7 1.04x
💻 Local Express 6.192s (-17.8% 🟢) 7.015s (-12.6% 🟢) 0.823s 5 1.71x
💻 Local Nitro 7.011s (-5.2% 🟢) 7.516s (-6.3% 🟢) 0.505s 4 1.93x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 3.232s (+0.5%) 4.512s (-3.8%) 1.280s 7 1.00x
▲ Vercel Express 3.765s (+20.7% 🔺) 4.812s (+10.4% 🔺) 1.046s 7 1.16x
▲ Vercel Next.js (Turbopack) 3.967s (+10.3% 🔺) 5.057s (+9.0% 🔺) 1.090s 6 1.23x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Express 1.355s (-5.2% 🟢) 2.005s (~) 0.650s 15 1.00x
🐘 Postgres Express 1.374s (+1.1%) 2.010s (~) 0.636s 15 1.01x
🐘 Postgres Nitro 1.386s (+1.6%) 2.011s (~) 0.625s 15 1.02x
💻 Local Nitro 1.429s (~) 2.005s (~) 0.576s 15 1.05x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Next.js (Turbopack) 2.188s (+8.1% 🔺) 3.172s (+3.4%) 0.984s 10 1.00x
▲ Vercel Express 2.205s (+4.4%) 3.166s (-5.8% 🟢) 0.960s 10 1.01x
▲ Vercel Nitro 2.224s (+4.0%) 2.970s (-2.2%) 0.746s 11 1.02x

🔍 Observability: Next.js (Turbopack) | Express | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Express 2.034s (+1.7%) 2.600s (+3.5%) 0.566s 12 1.00x
🐘 Postgres Nitro 2.074s (+5.9% 🔺) 2.679s (+8.2% 🔺) 0.605s 12 1.02x
💻 Local Express 2.417s (-9.4% 🟢) 3.008s (~) 0.590s 10 1.19x
💻 Local Nitro 2.615s (-5.0%) 3.008s (~) 0.393s 10 1.29x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 2.953s (+22.5% 🔺) 3.562s (+8.3% 🔺) 0.609s 9 1.00x
▲ Vercel Next.js (Turbopack) 3.370s (+33.5% 🔺) 4.422s (+32.5% 🔺) 1.051s 7 1.14x
▲ Vercel Express 3.438s (+48.8% 🔺) 4.189s (+22.3% 🔺) 0.752s 8 1.16x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🐘 Postgres 🥇 Nitro 3.511s (+9.3% 🔺) 4.315s (+10.8% 🔺) 0.805s 7 1.00x
🐘 Postgres Express 3.761s (+9.1% 🔺) 4.451s (+7.3% 🔺) 0.689s 7 1.07x
💻 Local Express 6.695s (-13.9% 🟢) 7.014s (-15.2% 🟢) 0.319s 5 1.91x
💻 Local Nitro 7.564s (-3.6%) 8.019s (-5.9% 🟢) 0.454s 4 2.15x
💻 Local Next.js (Turbopack) ⚠️ missing - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - -

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 3.447s (+6.2% 🔺) 4.363s (+4.0%) 0.916s 7 1.00x
▲ Vercel Next.js (Turbopack) 3.976s (+17.7% 🔺) 5.020s (+15.8% 🔺) 1.044s 6 1.15x
▲ Vercel Express 4.801s (+60.2% 🔺) 5.773s (+44.3% 🔺) 0.972s 7 1.39x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

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.109s (-37.3% 🟢) 1.002s (~) 0.009s (-12.8% 🟢) 1.014s (~) 0.906s 10 1.00x
💻 Local Nitro 0.182s (+2.8%) 1.002s (~) 0.011s (-3.6%) 1.016s (~) 0.834s 10 1.68x
🐘 Postgres Express 0.189s (-1.8%) 0.997s (+0.5%) 0.001s (-6.7% 🟢) 1.012s (~) 0.822s 10 1.74x
🐘 Postgres Nitro 0.194s (-1.6%) 0.996s (~) 0.001s (-17.6% 🟢) 1.013s (~) 0.820s 10 1.78x
💻 Local Next.js (Turbopack) ⚠️ missing - - - - -
🐘 Postgres Next.js (Turbopack) ⚠️ missing - - - - -

▲ Production (Vercel)

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Express 1.615s (+3.2%) 2.237s (+18.6% 🔺) 0.101s (-4.4%) 2.705s (+10.1% 🔺) 1.090s 10 1.00x
▲ Vercel Next.js (Turbopack) 1.639s (+11.1% 🔺) 2.160s (+23.6% 🔺) 0.095s (~) 2.688s (+20.1% 🔺) 1.050s 10 1.01x
▲ Vercel Nitro 1.787s (+26.0% 🔺) 2.509s (+47.8% 🔺) 0.081s (-28.5% 🟢) 2.960s (+35.6% 🔺) 1.173s 10 1.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World 🥇 Fastest Framework Wins
💻 Local Express 12/12
🐘 Postgres Express 7/12
▲ Vercel Nitro 7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework 🥇 Fastest World Wins
Express 💻 Local 7/12
Next.js (Turbopack) ▲ Vercel 12/12
Nitro 🐘 Postgres 7/12
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

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Feb 26, 2026

⚠️ No Changeset found

Latest commit: 9fe76fa

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Feb 26, 2026

🧪 E2E Test Results

Some tests failed

Summary

Passed Failed Skipped Total
✅ ▲ Vercel Production 523 0 49 572
✅ 💻 Local Development 556 0 68 624
✅ 📦 Local Production 556 0 68 624
❌ 🐘 Local Postgres 555 1 68 624
✅ 🪟 Windows 49 0 3 52
❌ 🌍 Community Worlds 111 45 9 165
✅ 📋 Other 135 0 21 156
Total 2485 46 286 2817

❌ Failed Tests

🐘 Local Postgres (1 failed)

astro-stable (1 failed):

  • webhookWorkflow
🌍 Community Worlds (45 failed)

turso (45 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • parallelSleepWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • 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 retry behavior workflow completes despite transient 5xx on step_completed
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (queue-based) - workflow and step endpoints respond to health check messages
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • stepFunctionAsStartArgWorkflow - step function reference passed as start() argument
  • cancelRun - cancelling a running workflow
  • cancelRun via CLI - cancelling a running workflow
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
App Passed Failed Skipped
✅ astro 47 0 5
✅ example 47 0 5
✅ express 47 0 5
✅ fastify 47 0 5
✅ hono 47 0 5
✅ nextjs-turbopack 50 0 2
✅ nextjs-webpack 50 0 2
✅ nitro 47 0 5
✅ nuxt 47 0 5
✅ sveltekit 47 0 5
✅ vite 47 0 5
✅ 💻 Local Development
App Passed Failed Skipped
✅ astro-stable 45 0 7
✅ express-stable 45 0 7
✅ fastify-stable 45 0 7
✅ hono-stable 45 0 7
✅ nextjs-turbopack-canary 49 0 3
✅ nextjs-turbopack-stable 49 0 3
✅ nextjs-webpack-canary 49 0 3
✅ nextjs-webpack-stable 49 0 3
✅ nitro-stable 45 0 7
✅ nuxt-stable 45 0 7
✅ sveltekit-stable 45 0 7
✅ vite-stable 45 0 7
✅ 📦 Local Production
App Passed Failed Skipped
✅ astro-stable 45 0 7
✅ express-stable 45 0 7
✅ fastify-stable 45 0 7
✅ hono-stable 45 0 7
✅ nextjs-turbopack-canary 49 0 3
✅ nextjs-turbopack-stable 49 0 3
✅ nextjs-webpack-canary 49 0 3
✅ nextjs-webpack-stable 49 0 3
✅ nitro-stable 45 0 7
✅ nuxt-stable 45 0 7
✅ sveltekit-stable 45 0 7
✅ vite-stable 45 0 7
❌ 🐘 Local Postgres
App Passed Failed Skipped
❌ astro-stable 44 1 7
✅ express-stable 45 0 7
✅ fastify-stable 45 0 7
✅ hono-stable 45 0 7
✅ nextjs-turbopack-canary 49 0 3
✅ nextjs-turbopack-stable 49 0 3
✅ nextjs-webpack-canary 49 0 3
✅ nextjs-webpack-stable 49 0 3
✅ nitro-stable 45 0 7
✅ nuxt-stable 45 0 7
✅ sveltekit-stable 45 0 7
✅ vite-stable 45 0 7
✅ 🪟 Windows
App Passed Failed Skipped
✅ nextjs-turbopack 49 0 3
❌ 🌍 Community Worlds
App Passed Failed Skipped
✅ mongodb-dev 3 0 0
✅ mongodb 49 0 3
✅ redis-dev 3 0 0
✅ redis 49 0 3
✅ turso-dev 3 0 0
❌ turso 4 45 3
✅ 📋 Other
App Passed Failed Skipped
✅ e2e-local-dev-nest-stable 45 0 7
✅ e2e-local-postgres-nest-stable 45 0 7
✅ e2e-local-prod-nest-stable 45 0 7

📋 View full workflow run


Some E2E test jobs failed:

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

Check the workflow run for details.

The first overload of events.create() accepts string | null, not just
null. Clients can provide their own runId for run_created events.
VaguelySerious
VaguelySerious previously approved these changes Feb 26, 2026

```typescript lineNumbers
import { getWorld } from "workflow/runtime";
import { getWorld, cancelRun } from "@workflow/core/runtime";
Copy link
Copy Markdown
Contributor

@pranaygp pranaygp Mar 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nah the correct way to programmatically cancel a run is await getRun(runId).cancel() - not cancelRun from world. We don't adequately document it though so good call on making this. We should include an example in getRun api reference for cancelling a run so that it's searchable by AI. right now it's not well documented

Also users should almost never be importing from @workflow/core for normal usage. workflow/api should be what people use for normal behavior. using getWorld is an advanced/low level features that will break often as we change things around and not meant to be relied on

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using getWorld is an advanced/low level features that will break often as we change things around and not meant to be relied on

At least once we actually have a different way of querying the same data, which we won't for a while? In which case it wouldn't hurt to document. Users could already be relying on it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should document it and then have to support it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also like I said, for now the fix is simple. we have run.cancel(). let's document that instead of telling people to use @workflow/core/runtime which is never meant to be user facing

@pranaygp pranaygp dismissed VaguelySerious’s stale review March 2, 2026 21:36

we shouldn't document and recommend cancelRun from @workflow/core/runtime. it should be run.cancel

Copy link
Copy Markdown
Contributor

@pranaygp pranaygp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good docs audit overall — most fixes here are correct and helpful. The interface updates, typo fixes, run.returnValue, import path corrections, and flightBookingTools rename are all verified against the source.

The main blocker is the cancelRun change (already discussed in the thread) — it needs to use the public API instead of an internal module.


```typescript lineNumbers
import { getWorld } from "workflow/runtime";
import { getWorld, cancelRun } from "@workflow/core/runtime";
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As pranaygp noted in the earlier thread, this should use the public API:

import { getRun } from "workflow/runtime";

export async function POST(req: Request) {
  const { runId } = await req.json();
  // ...
  const run = getRun(runId);
  await run.cancel();
  return Response.json({ status: "cancelled" });
}

cancelRun from @workflow/core/runtime is an internal function — users should never import from @workflow/core directly. getRun(runId).cancel() is the supported public API for this (exported from workflow/runtime).

events: {
// Create a new workflow run (runId must be null - server generates it)
create(runId: null, data: RunCreatedEventRequest, params?: CreateEventParams): Promise<EventResult>;
// Create a new workflow run (runId may be client-provided or null for server generation)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: The source code doc comment (interfaces.ts:130) says: "The runId may be provided by the client or left as null for the server to generate." Consider matching this wording exactly for consistency between source and docs.

@@ -34,10 +34,13 @@ A World connects workflows to the infrastructure that powers them. The World int
```typescript
interface World extends Storage, Queue, Streamer {
start?(): Promise<void>;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified: the close?() and getEncryptionKeyForRun?() additions match the actual World interface in packages/world/src/interfaces.ts exactly. 👍

johnlindquist added a commit that referenced this pull request Apr 6, 2026
Cherry-picked 6 still-needed fixes from #1200 that aren't covered by
this audit PR or #1516:
- Fix npx workflow description (observability)
- Remove fetch from restricted modules list (errors)
- Fix package name @workflow-worlds/postgres → @workflow/world-postgres (deploying)
- Fix stream wording (foundations/starting-workflows)
- Fix import path simple → simple-streaming (foundations/streaming)
- Add close(), getEncryptionKeyForRun(), writeToStreamMulti() to World interface,
  update create() and streamer signatures (deploying/building-a-world)
@johnlindquist
Copy link
Copy Markdown
Contributor Author

Closing — fixes have been dispositioned:

  • 3 fixes already on main (ai/index.mdx variable rename, ai/resumable-streams.mdx highlight bracket, ai/sleep-and-delays.mdx import/operator fixes) — these were merged in subsequent PRs.
  • 3 fixes covered by docs: March docs audit and alignment #1466 (get-world.mdx, start-invalid-workflow-function.mdx, astro.mdx) — docs: March docs audit and alignment #1466 has more comprehensive rewrites of these files that include these corrections.
  • 6 unique fixes cherry-picked into docs: March docs audit and alignment #1466 (observability CLI wording, fetch removal from restricted modules, package name fix, stream wording, import path fix, World/Streamer interface updates) — committed to march-docs-audit branch.

No content lost.

johnlindquist added a commit that referenced this pull request Apr 6, 2026
Cherry-picked 6 still-needed fixes from #1200 that aren't covered by
this audit PR or #1516:
- Fix npx workflow description (observability)
- Remove fetch from restricted modules list (errors)
- Fix package name @workflow-worlds/postgres → @workflow/world-postgres (deploying)
- Fix stream wording (foundations/starting-workflows)
- Fix import path simple → simple-streaming (foundations/streaming)
- Add close(), getEncryptionKeyForRun(), writeToStreamMulti() to World interface,
  update create() and streamer signatures (deploying/building-a-world)
johnlindquist added a commit that referenced this pull request Apr 6, 2026
Cherry-picked 6 still-needed fixes from #1200 that aren't covered by
this audit PR or #1516:
- Fix npx workflow description (observability)
- Remove fetch from restricted modules list (errors)
- Fix package name @workflow-worlds/postgres → @workflow/world-postgres (deploying)
- Fix stream wording (foundations/starting-workflows)
- Fix import path simple → simple-streaming (foundations/streaming)
- Add close(), getEncryptionKeyForRun(), writeToStreamMulti() to World interface,
  update create() and streamer signatures (deploying/building-a-world)
pranaygp pushed a commit that referenced this pull request Apr 7, 2026
* docs: clarify Next monorepo setup

Prevent confusion when Next.js apps live below the repository root and workflow code imports sibling workspace packages.

This documents the output tracing root requirement at the point where users configure withWorkflow, so monorepo setups follow the same working patterns as the shipped Next.js integration instead of failing due to unresolved workspace imports.

Ploop-Iter: 1

* ploop: iteration 2 checkpoint

Automated checkpoint commit.

Ploop-Iter: 2

* ploop: iteration 3 checkpoint

Automated checkpoint commit.

Ploop-Iter: 3

* docs: audit recent documentation coverage

Capture recent workflow documentation updates so the public docs and package guidance stay aligned with the implementation and current docs-typecheck behavior.

Ploop-Iter: 1

* docs: align docs-typecheck docs

Document the current docs verification contract so contributors do not assume JavaScript examples are type-checked when only TypeScript snippets are enforced today.

Add regression coverage around the README language and framework integration guidance to keep those docs aligned with the implemented Next.js and docs-typecheck behavior as future changes land.

Ploop-Iter: 2

* docs: add start() troubleshooting guidance

Document the most common causes of the invalid workflow function error so users can resolve start() failures from the API docs and Next.js setup flow without having to infer build-time requirements from runtime behavior.

Keep the new troubleshooting page aligned with the shipped runtime message and add regression coverage so future wording or cross-link changes do not silently break that guidance.

Ploop-Iter: 3

* docs: align NestJS setup docs

Document both supported NestJS module formats and add a regression check so the getting-started guide stays aligned with the package README as the integration evolves.

Ploop-Iter: 1

* docs: tighten NestJS CommonJS guidance

Keep the NestJS getting-started guide consistent across the ESM and CommonJS paths so readers do not mix module settings or import styles mid-setup.

Strengthen the docs regression coverage around the later guide sections so future edits are more likely to preserve the supported CommonJS path documented in the package README.

Ploop-Iter: 2

* docs: align docs with recent workflow guidance

Document the recently added troubleshooting and observability patterns so the public docs stay aligned with the behavior users now encounter in practice.

This keeps the NestJS guide, workflow API reference, and docs regression coverage in sync with the runtime-facing guidance from recent changes.

Ploop-Iter: 3

* docs: audit docs coverage

Why: keep the docs aligned with recent API and runtime behavior changes so examples and reference pages don’t drift from the supported surface.

Ploop-Iter: 1

* test: add docs audit guards

Add regression coverage for doc surfaces that are easy to drift from implementation so docs audits catch mismatches early and keep published guidance aligned with the supported API surface.

Ploop-Iter: 2

* docs: add docs audit guards

Keep new observability and server-testing guidance anchored to machine-readable interfaces so follow-up implementation changes do not silently drift away from the documented agent and automation patterns.

Ploop-Iter: 3

* docs: align observability troubleshooting guidance

Keep the docs consistent so users get the same guidance when debugging hook token collisions and correlating workflow events with platform logs.

This prevents the event-sourcing reference from drifting away from the observability and error docs, and adds guard tests to catch regressions.

Ploop-Iter: 1

* Remove the unreferenced image file img-a-clean-minimal-technical-architecture-d-2026-02-27T14-07-52-1.png from the repo root, workbench/fastify/public/index.html (a Nitro example mistakenly placed in the fastify workbench by a ploop checkpoint), all .claude/worktrees/* submodule references, and all 15 string-presence audit guard tests in packages/docs-typecheck/src/__tests__/ (they only assert keyword presence, not semantic correctness). None of these belong in the docs audit PR.

* Address all PR #1466 review feedback from VaguelySerious, pranaygp, and ijjk:

1. Remove the "Machine-Readable Surfaces" section from docs/content/docs/observability/index.mdx (reviewers say it's unnecessary and already in world docs)
2. Remove all @skip-typecheck annotations from durable-agent.mdx (8) and server-based.mdx (1) — types exist in built packages/ai/dist after pnpm build
3. In durable-agent.mdx, change "machine-readable tool activity" to "tool call details" in the stream() return description
4. In durable-agent.mdx "Aborting Long-Running Streams" section, add a warning callout that abortSignal is not yet supported (blocked by #1301), recommend timeout instead
5. In event-sourcing.mdx, update requestId description: "On Vercel, requestId is the platform request ID when available. Other worlds are not expected to provide a requestId."
6. In get-world.mdx, change "user-friendly names from the machine-readable workflowName field" to "human-readable names from the workflowName field"
7. In start-invalid-workflow-function.mdx, add "// Does NOT work" comment above the bad example line
8. In with-workflow.mdx: reframe outputFileTracingRoot as a workaround (Next.js auto-detects by default per ijjk); change options description from "control local development behavior" to "configure the Next.js integration"; scope the callout to "workflows.local options only affect local development"
9. Drop the withWorkflow() options callout from docs/content/docs/getting-started/next.mdx
10. Remove the Next.js-specific outputFileTracingRoot callout from framework-integrations.mdx
11. Add a Troubleshooting section with the start() invalid-workflow-function error to all 9 non-Next getting-started guides (astro, express, fastify, hono, nestjs, nitro, nuxt, sveltekit, vite), each with framework-appropriate config check in point 2

* docs: absorb unique accuracy fixes from PR #1200

Cherry-picked 6 still-needed fixes from #1200 that aren't covered by
this audit PR or #1516:
- Fix npx workflow description (observability)
- Remove fetch from restricted modules list (errors)
- Fix package name @workflow-worlds/postgres → @workflow/world-postgres (deploying)
- Fix stream wording (foundations/starting-workflows)
- Fix import path simple → simple-streaming (foundations/streaming)
- Add close(), getEncryptionKeyForRun(), writeToStreamMulti() to World interface,
  update create() and streamer signatures (deploying/building-a-world)

* docs: address review feedback on March docs audit

- durable-agent.mdx: "structured tool activity" → "tool call information"
  per VaguelySerious's suggestion
- next.mdx: drop monorepo callout from getting-started per pranaygp
  (too much context too early; info is in withWorkflow API ref)

* docs: fix 2 typecheck failures in encryption and nestjs guides

- encryption.mdx: add skip-typecheck for interface signature block
  (getEncryptionKeyForRun overloads are not runnable code)
- nestjs.mdx: add skip-typecheck for WorkflowModule.forRoot config
  snippet (fragment inside callout, full import shown above)

Verified: pnpm vitest run passes 300/300 in docs-typecheck.
VaguelySerious pushed a commit that referenced this pull request Apr 7, 2026
* docs: clarify Next monorepo setup

Prevent confusion when Next.js apps live below the repository root and workflow code imports sibling workspace packages.

This documents the output tracing root requirement at the point where users configure withWorkflow, so monorepo setups follow the same working patterns as the shipped Next.js integration instead of failing due to unresolved workspace imports.

Ploop-Iter: 1

* ploop: iteration 2 checkpoint

Automated checkpoint commit.

Ploop-Iter: 2

* ploop: iteration 3 checkpoint

Automated checkpoint commit.

Ploop-Iter: 3

* docs: audit recent documentation coverage

Capture recent workflow documentation updates so the public docs and package guidance stay aligned with the implementation and current docs-typecheck behavior.

Ploop-Iter: 1

* docs: align docs-typecheck docs

Document the current docs verification contract so contributors do not assume JavaScript examples are type-checked when only TypeScript snippets are enforced today.

Add regression coverage around the README language and framework integration guidance to keep those docs aligned with the implemented Next.js and docs-typecheck behavior as future changes land.

Ploop-Iter: 2

* docs: add start() troubleshooting guidance

Document the most common causes of the invalid workflow function error so users can resolve start() failures from the API docs and Next.js setup flow without having to infer build-time requirements from runtime behavior.

Keep the new troubleshooting page aligned with the shipped runtime message and add regression coverage so future wording or cross-link changes do not silently break that guidance.

Ploop-Iter: 3

* docs: align NestJS setup docs

Document both supported NestJS module formats and add a regression check so the getting-started guide stays aligned with the package README as the integration evolves.

Ploop-Iter: 1

* docs: tighten NestJS CommonJS guidance

Keep the NestJS getting-started guide consistent across the ESM and CommonJS paths so readers do not mix module settings or import styles mid-setup.

Strengthen the docs regression coverage around the later guide sections so future edits are more likely to preserve the supported CommonJS path documented in the package README.

Ploop-Iter: 2

* docs: align docs with recent workflow guidance

Document the recently added troubleshooting and observability patterns so the public docs stay aligned with the behavior users now encounter in practice.

This keeps the NestJS guide, workflow API reference, and docs regression coverage in sync with the runtime-facing guidance from recent changes.

Ploop-Iter: 3

* docs: audit docs coverage

Why: keep the docs aligned with recent API and runtime behavior changes so examples and reference pages don’t drift from the supported surface.

Ploop-Iter: 1

* test: add docs audit guards

Add regression coverage for doc surfaces that are easy to drift from implementation so docs audits catch mismatches early and keep published guidance aligned with the supported API surface.

Ploop-Iter: 2

* docs: add docs audit guards

Keep new observability and server-testing guidance anchored to machine-readable interfaces so follow-up implementation changes do not silently drift away from the documented agent and automation patterns.

Ploop-Iter: 3

* docs: align observability troubleshooting guidance

Keep the docs consistent so users get the same guidance when debugging hook token collisions and correlating workflow events with platform logs.

This prevents the event-sourcing reference from drifting away from the observability and error docs, and adds guard tests to catch regressions.

Ploop-Iter: 1

* Remove the unreferenced image file img-a-clean-minimal-technical-architecture-d-2026-02-27T14-07-52-1.png from the repo root, workbench/fastify/public/index.html (a Nitro example mistakenly placed in the fastify workbench by a ploop checkpoint), all .claude/worktrees/* submodule references, and all 15 string-presence audit guard tests in packages/docs-typecheck/src/__tests__/ (they only assert keyword presence, not semantic correctness). None of these belong in the docs audit PR.

* Address all PR #1466 review feedback from VaguelySerious, pranaygp, and ijjk:

1. Remove the "Machine-Readable Surfaces" section from docs/content/docs/observability/index.mdx (reviewers say it's unnecessary and already in world docs)
2. Remove all @skip-typecheck annotations from durable-agent.mdx (8) and server-based.mdx (1) — types exist in built packages/ai/dist after pnpm build
3. In durable-agent.mdx, change "machine-readable tool activity" to "tool call details" in the stream() return description
4. In durable-agent.mdx "Aborting Long-Running Streams" section, add a warning callout that abortSignal is not yet supported (blocked by #1301), recommend timeout instead
5. In event-sourcing.mdx, update requestId description: "On Vercel, requestId is the platform request ID when available. Other worlds are not expected to provide a requestId."
6. In get-world.mdx, change "user-friendly names from the machine-readable workflowName field" to "human-readable names from the workflowName field"
7. In start-invalid-workflow-function.mdx, add "// Does NOT work" comment above the bad example line
8. In with-workflow.mdx: reframe outputFileTracingRoot as a workaround (Next.js auto-detects by default per ijjk); change options description from "control local development behavior" to "configure the Next.js integration"; scope the callout to "workflows.local options only affect local development"
9. Drop the withWorkflow() options callout from docs/content/docs/getting-started/next.mdx
10. Remove the Next.js-specific outputFileTracingRoot callout from framework-integrations.mdx
11. Add a Troubleshooting section with the start() invalid-workflow-function error to all 9 non-Next getting-started guides (astro, express, fastify, hono, nestjs, nitro, nuxt, sveltekit, vite), each with framework-appropriate config check in point 2

* docs: absorb unique accuracy fixes from PR #1200

Cherry-picked 6 still-needed fixes from #1200 that aren't covered by
this audit PR or #1516:
- Fix npx workflow description (observability)
- Remove fetch from restricted modules list (errors)
- Fix package name @workflow-worlds/postgres → @workflow/world-postgres (deploying)
- Fix stream wording (foundations/starting-workflows)
- Fix import path simple → simple-streaming (foundations/streaming)
- Add close(), getEncryptionKeyForRun(), writeToStreamMulti() to World interface,
  update create() and streamer signatures (deploying/building-a-world)

* docs: address review feedback on March docs audit

- durable-agent.mdx: "structured tool activity" → "tool call information"
  per VaguelySerious's suggestion
- next.mdx: drop monorepo callout from getting-started per pranaygp
  (too much context too early; info is in withWorkflow API ref)

* docs: fix 2 typecheck failures in encryption and nestjs guides

- encryption.mdx: add skip-typecheck for interface signature block
  (getEncryptionKeyForRun overloads are not runnable code)
- nestjs.mdx: add skip-typecheck for WorkflowModule.forRoot config
  snippet (fragment inside callout, full import shown above)

Verified: pnpm vitest run passes 300/300 in docs-typecheck.
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.

3 participants