Skip to content

Remove "workflow/internal/serialization" export#1082

Merged
TooTallNate merged 3 commits intomainfrom
02-16-remove_workflow_internal_serialization_export
Feb 16, 2026
Merged

Remove "workflow/internal/serialization" export#1082
TooTallNate merged 3 commits intomainfrom
02-16-remove_workflow_internal_serialization_export

Conversation

@TooTallNate
Copy link
Copy Markdown
Member

Was only being used in these two e2e test files and the data being passed in those tests don't rely on any specialized data types, so just use JSON there.

Was only being used in these two e2e test files and the data being passed in those tests don't rely on any specialized data types, so just use JSON there.
@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Feb 16, 2026

🦋 Changeset detected

Latest commit: aa8c9bd

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

This PR includes changesets to release 14 packages
Name Type
workflow Patch
@workflow/world-testing Patch
@workflow/core Patch
@workflow/builders Patch
@workflow/cli Patch
@workflow/next Patch
@workflow/nitro 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 Feb 16, 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.032s (-6.9% 🟢) 1.005s (~) 0.973s 10 1.00x
💻 Local Nitro 0.032s (+2.5%) 1.005s (~) 0.972s 10 1.00x
💻 Local Next.js (Turbopack) 0.043s 1.005s 0.962s 10 1.33x
🌐 Redis Next.js (Turbopack) 0.056s 1.005s 0.949s 10 1.74x
🌐 MongoDB Next.js (Turbopack) 0.103s 1.007s 0.904s 10 3.21x
🐘 Postgres Express 0.155s (-23.4% 🟢) 1.010s (-0.8%) 0.854s 10 4.82x
🐘 Postgres Nitro 0.251s (+10.8% 🔺) 1.010s (-0.9%) 0.758s 10 7.81x
🐘 Postgres Next.js (Turbopack) 0.370s 1.009s 0.639s 10 11.50x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 0.544s (-14.7% 🟢) 1.950s (-9.5% 🟢) 1.405s 10 1.00x
▲ Vercel Next.js (Turbopack) 0.597s (-27.3% 🟢) 1.924s (-10.9% 🟢) 1.327s 10 1.10x
▲ Vercel Express 0.654s (+8.9% 🔺) 2.105s (+2.0%) 1.451s 10 1.20x

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

workflow with 1 step

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Next.js (Turbopack) 1.096s 2.006s 0.910s 10 1.00x
💻 Local Express 1.105s (~) 2.006s (~) 0.901s 10 1.01x
💻 Local Nitro 1.106s (~) 2.006s (~) 0.901s 10 1.01x
🌐 Redis Next.js (Turbopack) 1.130s 2.007s 0.877s 10 1.03x
🌐 MongoDB Next.js (Turbopack) 1.310s 2.008s 0.698s 10 1.20x
🐘 Postgres Next.js (Turbopack) 2.254s 3.015s 0.761s 10 2.06x
🐘 Postgres Express 2.376s (-3.5%) 3.014s (~) 0.638s 10 2.17x
🐘 Postgres Nitro 2.425s (+6.8% 🔺) 3.014s (+7.1% 🔺) 0.590s 10 2.21x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Next.js (Turbopack) 2.276s (-5.5% 🟢) 3.134s (-10.2% 🟢) 0.858s 10 1.00x
▲ Vercel Nitro 2.337s (+1.7%) 3.339s (-8.6% 🟢) 1.003s 10 1.03x
▲ Vercel Express 2.746s (+21.6% 🔺) 3.740s (+11.4% 🔺) 0.995s 10 1.21x

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

workflow with 10 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Next.js (Turbopack) 10.745s 11.021s 0.276s 3 1.00x
💻 Local Express 10.822s (-0.6%) 11.021s (~) 0.199s 3 1.01x
🌐 Redis Next.js (Turbopack) 10.831s 11.026s 0.195s 3 1.01x
💻 Local Nitro 10.838s (~) 11.023s (~) 0.185s 3 1.01x
🌐 MongoDB Next.js (Turbopack) 12.321s 13.025s 0.704s 3 1.15x
🐘 Postgres Next.js (Turbopack) 15.142s 16.046s 0.904s 2 1.41x
🐘 Postgres Nitro 20.293s (+33.2% 🔺) 21.058s (+31.2% 🔺) 0.766s 2 1.89x
🐘 Postgres Express 20.404s (+6.9% 🔺) 21.059s (+7.7% 🔺) 0.656s 2 1.90x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Next.js (Turbopack) 17.672s (-0.7%) 18.305s (-3.7%) 0.633s 2 1.00x
▲ Vercel Express 17.692s (~) 18.568s (-1.8%) 0.876s 2 1.00x
▲ Vercel Nitro 17.791s (+2.4%) 18.766s (~) 0.975s 2 1.01x

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

workflow with 25 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Next.js (Turbopack) 27.189s 28.050s 0.862s 3 1.00x
🌐 Redis Next.js (Turbopack) 27.233s 28.058s 0.825s 3 1.00x
💻 Local Nitro 27.534s (~) 28.054s (~) 0.520s 3 1.01x
💻 Local Express 27.549s (~) 28.053s (~) 0.504s 3 1.01x
🌐 MongoDB Next.js (Turbopack) 30.633s 31.056s 0.424s 2 1.13x
🐘 Postgres Next.js (Turbopack) 37.971s 38.090s 0.118s 2 1.40x
🐘 Postgres Express 50.161s (+30.6% 🔺) 50.629s (+29.5% 🔺) 0.468s 2 1.84x
🐘 Postgres Nitro 50.337s (+32.9% 🔺) 51.131s (+34.2% 🔺) 0.795s 2 1.85x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Express 69.695s (+54.5% 🔺) 70.938s (+53.0% 🔺) 1.243s 1 1.00x
▲ Vercel Nitro 70.423s (+66.2% 🔺) 71.351s (+63.6% 🔺) 0.928s 1 1.01x
▲ Vercel Next.js (Turbopack) 70.900s (+64.7% 🔺) 72.015s (+63.7% 🔺) 1.115s 1 1.02x

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

workflow with 50 sequential steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🌐 Redis 🥇 Next.js (Turbopack) 54.959s 55.107s 0.147s 2 1.00x
💻 Local Next.js (Turbopack) 56.821s 57.098s 0.277s 2 1.03x
💻 Local Nitro 57.415s (~) 58.105s (~) 0.690s 2 1.04x
💻 Local Express 57.420s (~) 58.102s (~) 0.682s 2 1.04x
🌐 MongoDB Next.js (Turbopack) 61.261s 62.089s 0.828s 2 1.11x
🐘 Postgres Next.js (Turbopack) 70.379s 70.653s 0.274s 2 1.28x
🐘 Postgres Nitro 100.268s (+33.2% 🔺) 101.233s (+32.9% 🔺) 0.965s 1 1.82x
🐘 Postgres Express 100.368s (+32.8% 🔺) 101.239s (+32.9% 🔺) 0.871s 1 1.83x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Express 88.970s (-4.8%) 90.053s (-5.1% 🟢) 1.083s 1 1.00x
▲ Vercel Next.js (Turbopack) 92.487s (~) 92.957s (-1.2%) 0.470s 1 1.04x
▲ Vercel Nitro 92.749s (~) 93.604s (~) 0.855s 1 1.04x

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

Promise.all with 10 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🌐 Redis 🥇 Next.js (Turbopack) 1.294s 2.007s 0.713s 15 1.00x
💻 Local Express 1.417s (-0.6%) 2.006s (~) 0.588s 15 1.10x
💻 Local Next.js (Turbopack) 1.423s 2.006s 0.583s 15 1.10x
💻 Local Nitro 1.437s (+3.1%) 2.006s (~) 0.569s 15 1.11x
🐘 Postgres Next.js (Turbopack) 1.993s 2.473s 0.480s 13 1.54x
🌐 MongoDB Next.js (Turbopack) 2.169s 3.009s 0.840s 10 1.68x
🐘 Postgres Nitro 2.313s (+4.6%) 3.014s (+12.5% 🔺) 0.701s 10 1.79x
🐘 Postgres Express 2.373s (+21.7% 🔺) 3.013s (+35.4% 🔺) 0.640s 10 1.83x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Next.js (Turbopack) 2.497s (-39.3% 🟢) 3.294s (-37.6% 🟢) 0.798s 10 1.00x
▲ Vercel Express 2.670s (-70.5% 🟢) 3.634s (-68.7% 🟢) 0.964s 9 1.07x
▲ Vercel Nitro 2.807s (-70.1% 🟢) 3.832s (-68.6% 🟢) 1.024s 8 1.12x

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

Promise.all with 25 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Next.js (Turbopack) 2.560s 3.008s 0.448s 10 1.00x
💻 Local Express 2.610s (-7.6% 🟢) 3.007s (~) 0.398s 10 1.02x
🌐 Redis Next.js (Turbopack) 2.612s 3.009s 0.397s 10 1.02x
💻 Local Nitro 2.708s (+5.2% 🔺) 3.007s (~) 0.299s 10 1.06x
🌐 MongoDB Next.js (Turbopack) 4.772s 5.180s 0.408s 6 1.86x
🐘 Postgres Express 8.159s (-12.9% 🟢) 8.527s (-12.8% 🟢) 0.368s 4 3.19x
🐘 Postgres Nitro 9.134s (-8.4% 🟢) 9.536s (-7.3% 🟢) 0.402s 4 3.57x
🐘 Postgres Next.js (Turbopack) 12.189s 12.367s 0.178s 3 4.76x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Next.js (Turbopack) 2.961s (-82.2% 🟢) 3.854s (-78.2% 🟢) 0.894s 8 1.00x
▲ Vercel Express 3.024s (-83.0% 🟢) 4.186s (-78.4% 🟢) 1.162s 8 1.02x
▲ Vercel Nitro 3.030s (-78.9% 🟢) 3.872s (-75.1% 🟢) 0.842s 8 1.02x

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

Promise.all with 50 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🌐 Redis 🥇 Next.js (Turbopack) 4.130s 5.013s 0.883s 6 1.00x
💻 Local Express 7.513s (-10.7% 🟢) 8.017s (-11.1% 🟢) 0.505s 4 1.82x
💻 Local Next.js (Turbopack) 7.596s 8.265s 0.669s 4 1.84x
💻 Local Nitro 7.637s (+5.4% 🔺) 8.020s (~) 0.383s 4 1.85x
🌐 MongoDB Next.js (Turbopack) 9.989s 10.683s 0.694s 3 2.42x
🐘 Postgres Nitro 41.518s (-16.0% 🟢) 42.127s (-15.9% 🟢) 0.609s 1 10.05x
🐘 Postgres Express 49.459s (-3.1%) 50.130s (-2.0%) 0.671s 1 11.98x
🐘 Postgres Next.js (Turbopack) 56.245s 57.121s 0.876s 1 13.62x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 3.822s (-83.1% 🟢) 5.752s (-75.8% 🟢) 1.929s 6 1.00x
▲ Vercel Next.js (Turbopack) 3.886s (-80.6% 🟢) 4.752s (-77.2% 🟢) 0.866s 7 1.02x
▲ Vercel Express 6.036s (+45.8% 🔺) 7.351s (+34.5% 🔺) 1.315s 5 1.58x

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

Promise.race with 10 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🌐 Redis 🥇 Next.js (Turbopack) 1.260s 2.007s 0.746s 15 1.00x
💻 Local Express 1.413s (-4.4%) 2.006s (~) 0.593s 15 1.12x
💻 Local Next.js (Turbopack) 1.435s 2.005s 0.570s 15 1.14x
💻 Local Nitro 1.442s (+1.0%) 2.006s (~) 0.563s 15 1.14x
🐘 Postgres Next.js (Turbopack) 1.628s 2.011s 0.383s 15 1.29x
🐘 Postgres Nitro 2.034s (-5.5% 🟢) 2.922s (+6.6% 🔺) 0.888s 11 1.61x
🐘 Postgres Express 2.054s (-3.4%) 2.681s (+3.3%) 0.627s 12 1.63x
🌐 MongoDB Next.js (Turbopack) 2.170s 3.007s 0.837s 10 1.72x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 2.243s (-5.5% 🟢) 3.190s (-5.1% 🟢) 0.947s 10 1.00x
▲ Vercel Next.js (Turbopack) 2.279s (-4.7%) 3.202s (-2.6%) 0.924s 10 1.02x
▲ Vercel Express 2.343s (+4.7%) 3.500s (+8.7% 🔺) 1.156s 9 1.04x

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

Promise.race with 25 concurrent steps

💻 Local Development

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
🌐 Redis 🥇 Next.js (Turbopack) 2.545s 3.009s 0.464s 10 1.00x
💻 Local Next.js (Turbopack) 2.657s 3.009s 0.352s 10 1.04x
💻 Local Express 2.730s (-3.8%) 3.008s (~) 0.279s 10 1.07x
💻 Local Nitro 2.745s (+1.1%) 3.008s (~) 0.262s 10 1.08x
🌐 MongoDB Next.js (Turbopack) 4.737s 5.175s 0.438s 6 1.86x
🐘 Postgres Express 10.086s (-17.6% 🟢) 10.696s (-15.8% 🟢) 0.610s 3 3.96x
🐘 Postgres Nitro 10.218s (+2.1%) 11.032s (+3.1%) 0.815s 3 4.02x
🐘 Postgres Next.js (Turbopack) 13.493s 13.703s 0.210s 3 5.30x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 2.400s (-22.6% 🟢) 3.309s (-19.9% 🟢) 0.909s 10 1.00x
▲ Vercel Next.js (Turbopack) 2.418s (-9.1% 🟢) 3.105s (-16.2% 🟢) 0.687s 10 1.01x
▲ Vercel Express 2.790s (-9.9% 🟢) 3.753s (-7.1% 🟢) 0.963s 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
🌐 Redis 🥇 Next.js (Turbopack) 4.166s 5.012s 0.846s 6 1.00x
💻 Local Next.js (Turbopack) 7.619s 8.016s 0.398s 4 1.83x
💻 Local Express 8.076s (-6.4% 🟢) 8.773s (-2.8%) 0.697s 4 1.94x
💻 Local Nitro 8.131s (+5.2% 🔺) 9.021s (+9.1% 🔺) 0.890s 4 1.95x
🌐 MongoDB Next.js (Turbopack) 9.835s 10.349s 0.513s 3 2.36x
🐘 Postgres Express 50.121s (-2.8%) 51.108s (-1.9%) 0.987s 1 12.03x
🐘 Postgres Nitro 50.610s (+0.9%) 51.124s (~) 0.514s 1 12.15x
🐘 Postgres Next.js (Turbopack) 56.644s 57.134s 0.490s 1 13.60x

▲ Production (Vercel)

World Framework Workflow Time Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Express 2.941s (-3.2%) 4.317s (+10.5% 🔺) 1.376s 7 1.00x
▲ Vercel Nitro 3.249s (+11.5% 🔺) 4.335s (+6.0% 🔺) 1.085s 8 1.10x
▲ Vercel Next.js (Turbopack) 4.099s (+28.6% 🔺) 5.068s (+25.3% 🔺) 0.969s 6 1.39x

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

Stream Benchmarks (includes TTFB metrics)
workflow with stream

💻 Local Development

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
💻 Local 🥇 Next.js (Turbopack) 0.147s 1.002s 0.012s 1.017s 0.870s 10 1.00x
🌐 Redis Next.js (Turbopack) 0.170s 1.000s 0.002s 1.008s 0.838s 10 1.16x
💻 Local Nitro 0.173s (+2.2%) 1.002s (~) 0.011s (+0.9%) 1.017s (~) 0.844s 10 1.17x
💻 Local Express 0.175s (-3.2%) 1.002s (~) 0.011s (-5.1% 🟢) 1.016s (~) 0.842s 10 1.19x
🌐 MongoDB Next.js (Turbopack) 0.492s 0.956s 0.001s 1.009s 0.517s 10 3.35x
🐘 Postgres Next.js (Turbopack) 0.782s 0.750s 0.001s 1.010s 0.228s 10 5.32x
🐘 Postgres Nitro 2.372s (+76.5% 🔺) 2.672s (+57.6% 🔺) 0.001s (+16.7% 🔺) 3.015s (+49.8% 🔺) 0.644s 10 16.12x
🐘 Postgres Express 2.473s (+69.1% 🔺) 2.569s (+55.2% 🔺) 0.002s (+25.0% 🔺) 3.015s (+49.8% 🔺) 0.542s 10 16.81x

▲ Production (Vercel)

World Framework Workflow Time TTFB Slurp Wall Time Overhead Samples vs Fastest
▲ Vercel 🥇 Nitro 2.068s (-21.7% 🟢) 2.618s (-27.6% 🟢) 0.180s (-13.3% 🟢) 3.394s (-22.4% 🟢) 1.326s 10 1.00x
▲ Vercel Next.js (Turbopack) 2.147s (+5.4% 🔺) 2.583s (-1.2%) 0.227s (-2.6%) 3.457s (~) 1.310s 10 1.04x
▲ Vercel Express 2.244s (-28.9% 🟢) 2.818s (-45.6% 🟢) 0.244s (+29.3% 🔺) 3.719s (-39.2% 🟢) 1.475s 10 1.08x

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

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World 🥇 Fastest Framework Wins
💻 Local Next.js (Turbopack) 8/12
🐘 Postgres Next.js (Turbopack) 7/12
▲ Vercel Nitro 5/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework 🥇 Fastest World Wins
Express 💻 Local 10/12
Next.js (Turbopack) 💻 Local 6/12
Nitro 💻 Local 9/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

@TooTallNate TooTallNate marked this pull request as ready for review February 16, 2026 17:27
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Feb 16, 2026

🧪 E2E Test Results

Some tests failed

Summary

Passed Failed Skipped Total
✅ ▲ Vercel Production 512 0 38 550
✅ 💻 Local Development 532 0 68 600
✅ 📦 Local Production 532 0 68 600
✅ 🐘 Local Postgres 532 0 68 600
✅ 🪟 Windows 47 0 3 50
❌ 🌍 Community Worlds 107 43 9 159
✅ 📋 Other 129 0 21 150
Total 2391 43 275 2709

❌ Failed Tests

🌍 Community Worlds (43 failed)

turso (43 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
  • 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 46 0 4
✅ example 46 0 4
✅ express 46 0 4
✅ fastify 46 0 4
✅ hono 46 0 4
✅ nextjs-turbopack 49 0 1
✅ nextjs-webpack 49 0 1
✅ nitro 46 0 4
✅ nuxt 46 0 4
✅ sveltekit 46 0 4
✅ vite 46 0 4
✅ 💻 Local Development
App Passed Failed Skipped
✅ astro-stable 43 0 7
✅ express-stable 43 0 7
✅ fastify-stable 43 0 7
✅ hono-stable 43 0 7
✅ nextjs-turbopack-canary 47 0 3
✅ nextjs-turbopack-stable 47 0 3
✅ nextjs-webpack-canary 47 0 3
✅ nextjs-webpack-stable 47 0 3
✅ nitro-stable 43 0 7
✅ nuxt-stable 43 0 7
✅ sveltekit-stable 43 0 7
✅ vite-stable 43 0 7
✅ 📦 Local Production
App Passed Failed Skipped
✅ astro-stable 43 0 7
✅ express-stable 43 0 7
✅ fastify-stable 43 0 7
✅ hono-stable 43 0 7
✅ nextjs-turbopack-canary 47 0 3
✅ nextjs-turbopack-stable 47 0 3
✅ nextjs-webpack-canary 47 0 3
✅ nextjs-webpack-stable 47 0 3
✅ nitro-stable 43 0 7
✅ nuxt-stable 43 0 7
✅ sveltekit-stable 43 0 7
✅ vite-stable 43 0 7
✅ 🐘 Local Postgres
App Passed Failed Skipped
✅ astro-stable 43 0 7
✅ express-stable 43 0 7
✅ fastify-stable 43 0 7
✅ hono-stable 43 0 7
✅ nextjs-turbopack-canary 47 0 3
✅ nextjs-turbopack-stable 47 0 3
✅ nextjs-webpack-canary 47 0 3
✅ nextjs-webpack-stable 47 0 3
✅ nitro-stable 43 0 7
✅ nuxt-stable 43 0 7
✅ sveltekit-stable 43 0 7
✅ vite-stable 43 0 7
✅ 🪟 Windows
App Passed Failed Skipped
✅ nextjs-turbopack 47 0 3
❌ 🌍 Community Worlds
App Passed Failed Skipped
✅ mongodb-dev 3 0 0
✅ mongodb 47 0 3
✅ redis-dev 3 0 0
✅ redis 47 0 3
✅ turso-dev 3 0 0
❌ turso 4 43 3
✅ 📋 Other
App Passed Failed Skipped
✅ e2e-local-dev-nest-stable 43 0 7
✅ e2e-local-postgres-nest-stable 43 0 7
✅ e2e-local-prod-nest-stable 43 0 7

📋 View full workflow run

Copilot AI review requested due to automatic review settings February 16, 2026 17:27
Copy link
Copy Markdown
Member Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@vercel
Copy link
Copy Markdown
Contributor

vercel Bot commented Feb 16, 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 Feb 16, 2026 5:56pm
example-nextjs-workflow-webpack Ready Ready Preview, Comment Feb 16, 2026 5:56pm
example-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-astro-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-express-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-fastify-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-hono-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-nitro-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-nuxt-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-sveltekit-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workbench-vite-workflow Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workflow-nest Ready Ready Preview, Comment Feb 16, 2026 5:56pm
workflow-swc-playground Ready Ready Preview, Comment Feb 16, 2026 5:56pm
1 Skipped Deployment
Project Deployment Actions Updated (UTC)
workflow-docs Skipped Skipped Feb 16, 2026 5:56pm

@TooTallNate TooTallNate requested review from a team and removed request for Copilot February 16, 2026 17:27
Comment thread packages/workflow/package.json
…ge.json breaks 5 files in `packages/world-testing` that still import `hydrateWorkflowReturnValue` from that path.

Co-authored-by: TooTallNate <n@n8.io>
Copilot AI review requested due to automatic review settings February 16, 2026 17:52
@TooTallNate TooTallNate review requested due to automatic review settings February 16, 2026 17:52
@vercel vercel Bot temporarily deployed to Preview – workflow-docs February 16, 2026 17:52 Inactive
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This pull request removes the workflow/internal/serialization export which was only being used in e2e test files. The changes simplify the codebase by:

  • Removing the re-export wrapper in the workflow package
  • Migrating test files to use direct imports from @workflow/core/serialization
  • Simplifying NextJS Pages Router API endpoints to use JSON instead of binary serialization

Changes:

  • Removed workflow/internal/serialization export from the workflow package
  • Updated world-testing files to import from @workflow/core/serialization directly
  • Simplified NextJS test API endpoints to use JSON body parsing instead of binary serialization

Reviewed changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated no comments.

Show a summary per file
File Description
packages/workflow/src/internal/serialization.ts Deleted re-export file
packages/workflow/package.json Removed export entry for internal/serialization
workbench/nextjs-webpack/pages/api/trigger-pages.ts Removed binary serialization logic, simplified to use JSON body or query params
workbench/nextjs-turbopack/pages/api/trigger-pages.ts Removed binary serialization logic, simplified to use JSON body or query params
packages/world-testing/src/*.mts Updated imports to use @workflow/core/serialization
packages/world-testing/package.json Added @workflow/core dependency
pnpm-lock.yaml Updated lockfile for new dependency
.changeset/cyan-ravens-eat.md Added changeset documenting the removal
Files not reviewed (1)
  • pnpm-lock.yaml: Language not supported

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@TooTallNate TooTallNate merged commit 0946dad into main Feb 16, 2026
110 checks passed
@TooTallNate TooTallNate deleted the 02-16-remove_workflow_internal_serialization_export branch February 16, 2026 19:50
pranaygp added a commit that referenced this pull request Feb 17, 2026
* origin/main:
  Remove "workflow/internal/serialization" export (#1082)
TooTallNate added a commit that referenced this pull request Apr 19, 2026
…/core/serialization/workflow sub-path

Both exports had zero consumers in the repo. The workflow/internal/serialization
export was previously removed on main in #1082 for the same reason. The
modular workflow.serialize/deserialize is still reachable via
@workflow/core/serialization when needed. These exports can be reintroduced
by the snapshot runtime branch if/when it actually needs them.

Also updates the changeset to drop the 'new sub-path exports' bullet.
TooTallNate added a commit that referenced this pull request Apr 30, 2026
…isites

Standardize on `Symbol.for('workflow-serialize')` /
`Symbol.for('workflow-deserialize')` everywhere — the parallel
`globalThis.__wdk_serialize` / `__wdk_deserialize` aliases have been
removed from `vm-bundle-entry.ts` and the snapshot runtime's inline
JS strings now use the symbol form directly. Single canonical name,
no duplication.

Drop the `?? Math.random` and `?? Date.now()` fallbacks from the
ULID generator setup. Both prerequisites
(`globalThis.__ulidTimestamp` and the host-replaced seeded
`Math.random`) are always set by `snapshot-runtime.ts` before the
serde bundle is evaluated; silently falling back to unseeded
`Math.random` or live `Date.now()` would re-introduce the
non-determinism we deliberately fixed (concurrent VM invocations of
the same resumption must produce identical correlationIds for the
world's EntityConflictError dedup to work). Now throws if
`__ulidTimestamp` isn't a number, and passes the seeded
`Math.random` reference explicitly to `monotonicFactory` so
upstream's `detectPRNG` never runs (it'd throw in QuickJS anyway,
since `crypto` is unavailable).

Drop the `URL` / `URLSearchParams` / `DOMException` availability
guards in `common-vm.ts`. quickjs-wasi's URL extension is always
loaded (`url.so`) and DOMException is always constructible — the
guards were dead code carried over from when those weren't reliably
available. The reducer/reviver code is now straightforward
`instanceof URL` / `new URL(...)` / `new DOMException(...)`.

Remove `packages/core/src/serialization/base64.ts` and its
sub-path exports (`./serialization/workflow`,
`./serialization/workflow-vm`). The pure-JS base64 helpers were
leftover from before `base64.so` shipped `btoa`/`atob` natively;
the VM-side reducers in `common-vm.ts` now build base64 strings via
the native ones. The sub-path exports had zero consumers in this
repo (the same cleanup landed on the `serialization-refactor`
branch in 05e0fee but never made it onto `snapshot-runtime`
because the branches diverged earlier).

Remove `packages/workflow/src/internal/serialization.ts` and its
`./internal/serialization` package.json export. Same story — zero
consumers, previously removed in #1082, then accidentally
reintroduced via `f04fd8e91`.
TooTallNate added a commit that referenced this pull request May 1, 2026
…to existing pipeline (#1299)

* Add serialization module foundation: types, codec interface, format prefix

Start of the serialization refactor (separate from snapshot-runtime).

New files:
- serialization/types.ts — SerializationFormat enum, SerializableSpecial
  interface, Reducers/Revivers types
- serialization/codec.ts — Codec interface with formatPrefix, serialize,
  deserialize, and optional deserializeLegacy
- serialization/format.ts — Format prefix encode/decode/peek, moved from
  the monolithic serialization.ts

The Codec interface enables future alternative formats (CBOR, JSON) while
keeping the devalue implementation as the current default.

* Add reducers, devalue codec, encryption, and mode-specific modules

Serialization refactor Phase 1: create the new module structure alongside
the existing monolithic serialization.ts (which continues to work).

New files:
- serialization/reducers/common.ts — Date, Error, Map, Set, URL, BigInt,
  typed arrays, Headers, Request, Response, RegExp, URLSearchParams
- serialization/reducers/class.ts — Class/Instance with WORKFLOW_SERIALIZE/
  DESERIALIZE support
- serialization/reducers/step-function.ts — StepFunction with closure vars
- serialization/codec-devalue.ts — devalue Codec implementation
- serialization/encryption.ts — composable encrypt/decrypt layer
- serialization/workflow.ts — synchronous, no encryption, for VM use
- serialization/step.ts — async with encryption, for step handler
- serialization/client.ts — async with encryption, for start() API
- serialization/index.ts — re-exports all public API
- serialization/serialization.test.ts — 25 focused tests

All modes compose their reducer/reviver sets from the shared building blocks.
Cross-mode compatibility verified: data serialized in any mode can be
deserialized in any other mode (for common types).

Existing 108 serialization tests continue to pass unchanged.

* Add sub-path exports for workflow serialization module

- Add ./serialization/workflow export to @workflow/core package.json
- Add ./internal/serialization re-export to workflow meta-package
- The workflow bundle can now import serialize/deserialize via:
  import { serialize, deserialize } from 'workflow/internal/serialization'

Full test suite passes: 493 tests across 22 files (including 25 new
serialization module tests).

* Address code review feedback

1. Fix reducer composition order: Class/Instance reducers now come BEFORE
   common reducers in all three modes (workflow, step, client). This ensures
   custom Error subclasses with WORKFLOW_SERIALIZE are handled by the
   Instance reducer before the generic Error reducer (devalue uses
   first-match-wins semantics).

2. Fix encryption decrypt() to fail fast when encrypted data is encountered
   without a decryption key, instead of silently returning encrypted bytes
   that would fail later with an unhelpful format error.

3. Remove Request/Response from common reducers — they don't have matching
   common revivers, so including them caused asymmetric behavior (serialize
   as Request, deserialize as plain object). Request/Response handling
   belongs in mode-specific modules that can provide proper revivers.

4. Document Node.js dependency in the workflow serialization re-export.
   The current implementation uses node:util and Buffer. For the QuickJS
   VM (snapshot runtime), these will need polyfills — tracked separately.

* Move reducer/reviver composition into the devalue codec

The Codec interface now takes a SerializationMode ('workflow', 'step',
'client') instead of raw reducers/revivers. The reducer/reviver
composition is internal to the devalue codec implementation.

This is the right abstraction because reducers/revivers are devalue-
specific concepts. A future CBOR codec would handle Date, typed arrays,
Map, Set natively via the CBOR type system — it wouldn't use reducers
at all. A JSON codec would only support standard JSON types.

The mode-specific modules (workflow.ts, step.ts, client.ts) are now
simpler — they just pass the mode string to the codec.

* Replace SerializationFormatType enum with open-ended FormatPrefix type

The format prefix is now a branded string type validated by
isFormatPrefix() — any 4-character [a-z0-9] string is valid.
This removes the hard-coded enum of known formats, making the system
truly open for extension:

  type FormatPrefix = string & { __brand: 'FormatPrefix' };
  function isFormatPrefix(value: string): value is FormatPrefix;

The SerializationFormat object still provides well-known constants
('devl', 'encr') but they're now just typed constants, not an
exhaustive enum.

peekFormatPrefix() and decodeFormatPrefix() use isFormatPrefix() for
validation instead of checking against a known list. Unknown but valid
prefixes (e.g. 'cbor', 'json', 'v2b1') are accepted — the caller
decides whether they can handle the format.

6 new isFormatPrefix tests covering: valid strings, too short, too long,
uppercase, special characters. 1 new test for unknown-but-valid prefixes.

* Wire modular serialization modules into serialization.ts, add 138 unit tests

Replace duplicate format prefix, reducer/reviver, and encryption helper
code in the monolithic serialization.ts with imports from the modular
serialization/ directory. This completes the refactoring started in the
earlier additive-only commits.

Key changes:
- serialization.ts now imports types, format prefix, common/class/step-function
  reducers and revivers, and encryption helpers from ./serialization/ modules
- Removed ~450 lines of duplicate code from serialization.ts
- Made encryption error messages consistent between old and new modules
- Added 138 comprehensive unit tests covering types, format prefix,
  encryption, codec, all three reducer modules, all three mode modules,
  cross-mode compatibility, and edge cases
- Updated one existing test assertion for new error message wording

* Address code review feedback

- encryption.ts: throw WorkflowRuntimeError instead of plain Error in
  decrypt() to preserve the error contract from legacy maybeDecrypt()
- format.ts: document that open-ended prefix validation ([a-z0-9]{4})
  is intentional for forward compatibility — callers check support
- errors.ts: extract duplicated formatSerializationError into shared
  utility, remove 4 copies from workflow.ts, step.ts, client.ts
- codec-devalue.ts: document that globalThis default is a known
  limitation; legacy dehydrate/hydrate path still supports custom global

* Fix codec-devalue.ts comment: clarify modular modules are not used in current runtime

The globalThis default is not a limitation for the current runtime —
all serialization goes through dehydrate*/hydrate* in serialization.ts
which passes the correct global. The modular modules are infrastructure
for the future snapshot runtime where serialization runs inside the VM.

* Wire dehydrate/hydrate functions through modular serialize/deserialize

The dehydrate*/hydrate* functions in serialization.ts now delegate to
the modular mode modules (workflowModule, stepModule, clientModule)
instead of directly calling devalue stringify/parse/unflatten.

Key changes:
- Extended Codec interface with CodecOptions (global, extraReducers,
  extraRevivers) so the codec can receive VM globals and mode-specific
  stream/Request/Response handlers
- devalueCodec threads global through to all reducer/reviver factories
  so instanceof checks work across VM boundaries
- Mode modules (workflow.ts, step.ts, client.ts) accept CodecOptions
  and pass them through to the codec
- dehydrate*/hydrate* functions now call module serialize/deserialize
  with stream and Request/Response reducers/revivers passed as extras
- v1Compat path remains inline (pre-codec, uses stringify + revive)
- Error context strings preserved via try/catch re-wrapping

* Bump changeset from patch to minor for serialization refactor

Return types of public get*Reducers/get*Revivers functions narrowed
from Reducers/Revivers to Partial<Reducers>/Partial<Revivers>, which
is a TypeScript-level breaking change. Also adds new sub-path exports
(@workflow/core/serialization/workflow, workflow/internal/serialization)
which is additive. Minor bump is the appropriate semver for both.

* Remove unused workflow/internal/serialization re-export and @workflow/core/serialization/workflow sub-path

Both exports had zero consumers in the repo. The workflow/internal/serialization
export was previously removed on main in #1082 for the same reason. The
modular workflow.serialize/deserialize is still reachable via
@workflow/core/serialization when needed. These exports can be reintroduced
by the snapshot runtime branch if/when it actually needs them.

Also updates the changeset to drop the 'new sub-path exports' bullet.

* Downgrade changeset from minor to patch

After auditing actual consumers of the narrowed return types
(getExternalReducers/getWorkflowReducers/getExternalRevivers/getWorkflowRevivers
now return Partial<Reducers>/Partial<Revivers>), no in-repo or external
consumer indexes specific keys on the returned object in a way that would
break. The only internal caller that did (runtime/run.ts) was updated in
this same PR. The narrowing is type-safer but effectively invisible at
runtime and for idiomatic callers that spread or forward the object.
Since the refactor is internally restructuring only, patch is the
appropriate semver bump.

* Trim serialization-refactor changeset

* Dedup formatSerializationError: import from serialization/errors.ts

The legacy serialization.ts had its own inlined copy of
formatSerializationError. Now that the helper is exported from
serialization/errors.ts (already consumed by workflow.ts/step.ts/client.ts),
import it here too to keep the single source of truth.
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