') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); e2e: replace fixed-sleep hook waits with event-driven waitForHook helper by TooTallNate · Pull Request #1879 · vercel/workflow · GitHub
Skip to content

e2e: replace fixed-sleep hook waits with event-driven waitForHook helper - #1879

Merged
TooTallNate merged 1 commit into
mainfrom
e2e-wait-for-hook
May 4, 2026
Merged

e2e: replace fixed-sleep hook waits with event-driven waitForHook helper#1879
TooTallNate merged 1 commit into
mainfrom
e2e-wait-for-hook

Conversation

@TooTallNate

Copy link
Copy Markdown
Member

Summary

Replaces 8 fixed setTimeout(5_000) waits in hook-related e2e tests with a waitForHook(token, { runId, timeoutMs, intervalMs }) helper that polls getHookByToken until it resolves or the timeout fires.

Background

Hook-related e2e tests (hookWorkflow, hookCleanupTestWorkflow, hookDisposeTestWorkflow, hookWithSleepWorkflow, distributedAbortController ×3) all sleep a fixed 5 seconds before calling getHookByToken, then assume the hook is registered. That budget is:

  • Too tight on slow runtimes — under load (e.g. parallel CI matrix, cold-start-heavy deployments) the workflow may not have reached its createHook call within 5s, and the test fails with HookNotFoundError.
  • Unnecessarily slow on fast runtimes — most invocations register the hook within ~500ms, leaving 4.5s of sunk time per test.

Fix

Adds a waitForHook helper at the top of packages/core/e2e/e2e.test.ts that polls (default 250ms interval, 30s timeout) and exits early on success. The optional runId filter handles eventually-consistent backends where a stale lookup may still resolve to a previous run's hook for the same token (used by hookCleanupTestWorkflow / hookDisposeTestWorkflow token-reuse cases).

Each affected call site replaces the setTimeout(5_000) → getHookByToken(token) pair with waitForHook(token, { runId: run.runId }). Non-hook fixed sleeps (the sleepingWorkflow cancel tests, payload-processing waits in hookWithSleepWorkflow) are untouched.

Verification

pnpm -F @workflow/core typecheck # clean
pnpm -F @workflow/core build # clean
pnpm -F @workflow/core test # 591 unit tests pass

The e2e file is exercised by the dedicated e2e CI pipeline against deployed worlds. Single-file change, 72 insertions / 49 deletions.

Extracted from PR #1300 (snapshot-runtime). The slowness issue was most visible on Vercel under the snapshot runtime where each round-trip is several seconds longer, but the fix makes the tests faster and more reliable on every runtime.

CopilotAI review requested due to automatic review settings April 30, 2026 08:26
@changeset-bot

changeset-botBot commented Apr 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 72f0617

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

This PR includes changesets to release 0 packages

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

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

@vercel

vercelBot commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actionsBot commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

All tests passed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production10110671078
✅ 💻 Local Development10900861176
✅ 📦 Local Production10900861176
✅ 🐘 Local Postgres10900861176
✅ 🪟 Windows980098
✅ 📋 Other276018294
Total465503434998

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro9107
✅ example9107
✅ express9107
✅ fastify9107
✅ hono9107
✅ nextjs-turbopack9602
✅ nextjs-webpack9602
✅ nitro9107
✅ nuxt9107
✅ sveltekit9107
✅ vite9107
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable9206
✅ express-stable9206
✅ fastify-stable9206
✅ hono-stable9206
✅ nextjs-turbopack-canary79019
✅ nextjs-turbopack-stable9800
✅ nextjs-webpack-canary79019
✅ nextjs-webpack-stable9800
✅ nitro-stable9206
✅ nuxt-stable9206
✅ sveltekit-stable9206
✅ vite-stable9206
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable9206
✅ express-stable9206
✅ fastify-stable9206
✅ hono-stable9206
✅ nextjs-turbopack-canary79019
✅ nextjs-turbopack-stable9800
✅ nextjs-webpack-canary79019
✅ nextjs-webpack-stable9800
✅ nitro-stable9206
✅ nuxt-stable9206
✅ sveltekit-stable9206
✅ vite-stable9206
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable9206
✅ express-stable9206
✅ fastify-stable9206
✅ hono-stable9206
✅ nextjs-turbopack-canary79019
✅ nextjs-turbopack-stable9800
✅ nextjs-webpack-canary79019
✅ nextjs-webpack-stable9800
✅ nitro-stable9206
✅ nuxt-stable9206
✅ sveltekit-stable9206
✅ vite-stable9206
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack9800
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable9206
✅ e2e-local-postgres-nest-stable9206
✅ e2e-local-prod-nest-stable9206

📋 View full workflow run

@github-actions

github-actionsBot commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

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

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Nitro0.042s (-3.7%)1.006s (~)0.964s101.00x
💻 LocalNext.js (Turbopack)0.042s1.004s0.962s101.02x
💻 LocalExpress0.045s (+1.8%)1.006s (~)0.960s101.09x
🐘 PostgresExpress0.052s (-9.7% 🟢)1.012s (~)0.959s101.26x
🐘 PostgresNitro0.059s (-38.1% 🟢)1.010s (-3.2%)0.951s101.42x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.095s2.006s0.911s101.00x
💻 LocalNitro1.125s (-0.5%)2.006s (~)0.881s101.03x
💻 LocalExpress1.127s (~)2.006s (~)0.880s101.03x
🐘 PostgresExpress1.136s (-0.9%)2.013s (~)0.877s101.04x
🐘 PostgresNitro1.143s (~)2.010s (~)0.866s101.04x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.649s11.022s0.373s31.00x
🐘 PostgresExpress10.773s (-1.7%)11.025s (~)0.252s31.01x
🐘 PostgresNitro10.884s (~)11.019s (~)0.135s31.02x
💻 LocalNitro10.932s (~)11.022s (~)0.090s31.03x
💻 LocalExpress10.964s (~)11.023s (~)0.059s31.03x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)14.160s15.030s0.870s41.00x
🐘 PostgresExpress14.223s (-2.5%)15.027s (~)0.804s41.00x
🐘 PostgresNitro14.594s (~)15.022s (~)0.428s41.03x
💻 LocalNitro14.979s (-0.6%)15.028s (-6.2% 🟢)0.049s41.06x
💻 LocalExpress15.011s (~)15.531s (+3.3%)0.520s41.06x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express13.296s (-5.1% 🟢)14.026s (-3.9%)0.730s71.00x
🐘 PostgresNitro14.131s (+1.2%)15.025s (+5.0% 🔺)0.894s61.06x
💻 LocalNext.js (Turbopack)14.756s15.027s0.271s61.11x
💻 LocalNitro16.643s (-0.8%)17.031s (~)0.387s61.25x
💻 LocalExpress16.785s (+1.1%)17.032s (~)0.247s61.26x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express1.229s (-2.5%)2.009s (~)0.779s151.00x
🐘 PostgresNitro1.268s (-0.5%)2.009s (~)0.741s151.03x
💻 LocalNext.js (Turbopack)1.444s2.005s0.561s151.17x
💻 LocalNitro1.506s (-7.7% 🟢)2.005s (-3.3%)0.500s151.22x
💻 LocalExpress1.511s (+1.5%)2.007s (~)0.496s151.23x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Nitro2.326s (-1.1%)3.008s (~)0.682s101.00x
🐘 PostgresExpress2.373s (+0.5%)3.010s (~)0.637s101.02x
💻 LocalNext.js (Turbopack)2.625s3.007s0.382s101.13x
💻 LocalNitro2.906s (-7.6% 🟢)3.108s (-20.0% 🟢)0.202s101.25x
💻 LocalExpress3.064s (+3.8%)3.759s (+8.9% 🔺)0.695s81.32x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express3.438s (-1.4%)4.012s (~)0.573s81.00x
🐘 PostgresNitro3.504s (+0.7%)4.011s (~)0.507s81.02x
💻 LocalNext.js (Turbopack)6.681s7.415s0.734s51.94x
💻 LocalNitro8.392s (+0.5%)9.022s (~)0.630s42.44x
💻 LocalExpress8.488s (+1.8%)9.021s (~)0.533s42.47x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express1.241s (-1.3%)2.009s (~)0.768s151.00x
🐘 PostgresNitro1.263s (~)2.008s (~)0.745s151.02x
💻 LocalNext.js (Turbopack)1.520s2.006s0.486s151.22x
💻 LocalExpress1.562s (-17.5% 🟢)2.006s (-15.1% 🟢)0.444s151.26x
💻 LocalNitro1.563s (-16.2% 🟢)2.006s (-14.3% 🟢)0.442s151.26x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express2.334s (~)3.011s (~)0.676s101.00x
🐘 PostgresNitro2.351s (+0.5%)3.009s (~)0.658s101.01x
💻 LocalNext.js (Turbopack)2.842s3.343s0.502s91.22x
💻 LocalNitro2.946s (-3.9%)3.564s (-8.3% 🟢)0.619s91.26x
💻 LocalExpress3.040s (-2.9%)3.886s (+3.3%)0.846s81.30x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Nitro3.450s (-0.9%)4.010s (~)0.559s81.00x
🐘 PostgresExpress3.489s (~)4.011s (~)0.522s81.01x
💻 LocalNext.js (Turbopack)7.165s7.515s0.350s42.08x
💻 LocalExpress8.780s (~)9.024s (-2.7%)0.243s42.54x
💻 LocalNitro8.936s (-2.3%)9.529s (-4.9%)0.593s42.59x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 10 sequential data payload steps (10KB)

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.665s1.004s0.339s601.00x
🐘 PostgresExpress0.689s (-17.9% 🟢)1.007s (-1.6%)0.318s601.04x
🐘 PostgresNitro0.831s (+1.2%)1.006s (~)0.175s601.25x
💻 LocalExpress1.005s (+2.1%)1.400s (+30.2% 🔺)0.396s431.51x
💻 LocalNitro1.095s (+11.7% 🔺)1.255s (+14.7% 🔺)0.160s481.65x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 25 sequential data payload steps (10KB)

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express1.642s (-16.9% 🟢)2.009s (-11.0% 🟢)0.367s451.00x
🐘 PostgresNitro1.961s (+1.7%)2.258s (+7.5% 🔺)0.297s401.19x
💻 LocalNext.js (Turbopack)2.129s3.007s0.878s301.30x
💻 LocalNitro3.035s (~)3.729s (-0.8%)0.695s251.85x
💻 LocalExpress3.072s (+1.9%)3.885s (+8.4% 🔺)0.813s241.87x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 50 sequential data payload steps (10KB)

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express3.488s (-12.6% 🟢)4.011s (-8.2% 🟢)0.524s301.00x
🐘 PostgresNitro4.016s (-2.1%)4.455s (-3.2%)0.439s271.15x
💻 LocalNext.js (Turbopack)7.091s7.640s0.548s162.03x
💻 LocalNitro9.200s (-1.1%)9.865s (-1.5%)0.665s132.64x
💻 LocalExpress9.257s (+0.5%)10.018s (~)0.762s122.65x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 10 concurrent data payload steps (10KB)

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express0.255s (-9.6% 🟢)1.008s (~)0.752s601.00x
🐘 PostgresNitro0.280s (-1.2%)1.007s (~)0.727s601.10x
💻 LocalNext.js (Turbopack)0.549s1.021s0.472s602.15x
💻 LocalExpress0.585s (+4.5%)1.005s (~)0.419s602.29x
💻 LocalNitro0.596s (-1.5%)1.004s (-1.7%)0.409s602.33x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 25 concurrent data payload steps (10KB)

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express0.413s (-19.0% 🟢)1.007s (~)0.594s901.00x
🐘 PostgresNitro0.481s (-3.1%)1.006s (~)0.525s901.17x
💻 LocalNext.js (Turbopack)2.407s3.007s0.600s305.83x
💻 LocalExpress2.535s (+0.9%)3.009s (~)0.474s306.14x
💻 LocalNitro2.557s (+0.7%)3.010s (~)0.453s306.20x
🐘 PostgresNext.js (Turbopack)⚠️missing----
workflow with 50 concurrent data payload steps (10KB)

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express0.665s (-18.8% 🟢)1.007s (-1.0%)0.342s1201.00x
🐘 PostgresNitro0.791s (~)1.008s (~)0.217s1201.19x
💻 LocalNext.js (Turbopack)9.263s9.795s0.532s1313.93x
💻 LocalExpress11.077s (-1.0%)11.756s (-1.5%)0.679s1116.66x
💻 LocalNitro11.085s (-0.9%)11.574s (-0.8%)0.488s1116.68x
🐘 PostgresNext.js (Turbopack)⚠️missing----
Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.139s1.002s0.010s1.015s0.877s101.00x
🐘 PostgresExpress0.176s (-13.9% 🟢)1.000s (~)0.001s (-31.3% 🟢)1.012s (~)0.835s101.27x
💻 LocalNitro0.202s (-5.7% 🟢)1.004s (~)0.012s (-5.6% 🟢)1.018s (~)0.817s101.45x
💻 LocalExpress0.204s (+2.7%)1.004s (~)0.013s (+4.1%)1.019s (~)0.814s101.47x
🐘 PostgresNitro0.218s (+6.1% 🔺)0.996s (~)0.001s (-33.3% 🟢)1.009s (~)0.792s101.57x
🐘 PostgresNext.js (Turbopack)⚠️missing-----
stream pipeline with 5 transform steps (1MB)

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Express0.592s (-6.0% 🟢)1.007s (~)0.004s (+4.9%)1.024s (~)0.432s591.00x
🐘 PostgresNitro0.612s (-1.9%)1.005s (~)0.004s (-7.4% 🟢)1.022s (~)0.409s591.03x
💻 LocalNext.js (Turbopack)0.662s1.009s0.010s1.114s0.453s541.12x
💻 LocalNitro0.753s (-10.2% 🟢)1.012s (~)0.010s (+6.4% 🔺)1.024s (-8.2% 🟢)0.271s591.27x
💻 LocalExpress0.864s (+14.2% 🔺)1.030s (~)0.014s (+48.9% 🔺)1.141s (+9.7% 🔺)0.277s531.46x
🐘 PostgresNext.js (Turbopack)⚠️missing-----
10 parallel streams (1MB each)

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Nitro0.986s (+1.7%)1.126s (-9.8% 🟢)0.000s (+35.8% 🔺)1.141s (-9.3% 🟢)0.155s531.00x
🐘 PostgresExpress1.042s (+8.4% 🔺)1.578s (+23.5% 🔺)0.000s (+81.6% 🔺)1.589s (+21.7% 🔺)0.547s381.06x
💻 LocalNext.js (Turbopack)1.174s2.016s0.000s2.019s0.845s301.19x
💻 LocalExpress1.236s (+0.9%)2.021s (~)0.000s (+40.0% 🔺)2.023s (~)0.787s301.25x
💻 LocalNitro1.282s (+4.8%)2.022s (~)0.000s (+200.0% 🔺)2.024s (~)0.742s301.30x
🐘 PostgresNext.js (Turbopack)⚠️missing-----
fan-out fan-in 10 streams (1MB each)

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
🐘 Postgres🥇 Nitro1.729s (-3.5%)2.104s (-1.8%)0.000s (-100.0% 🟢)2.129s (-2.1%)0.400s291.00x
🐘 PostgresExpress1.885s (+6.3% 🔺)2.309s (+6.1% 🔺)0.000s (NaN%)2.318s (+5.4% 🔺)0.434s261.09x
💻 LocalNext.js (Turbopack)3.461s4.028s0.001s4.033s0.572s152.00x
💻 LocalExpress3.539s (+2.1%)4.099s (+1.6%)0.000s (-41.7% 🟢)4.102s (+1.6%)0.563s152.05x
💻 LocalNitro3.594s (+6.1% 🔺)4.102s (+1.7%)0.001s (+62.5% 🔺)4.105s (+1.7%)0.511s152.08x
🐘 PostgresNext.js (Turbopack)⚠️missing-----

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)20/21
🐘 PostgresExpress17/21
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express🐘 Postgres19/21
Next.js (Turbopack)💻 Local21/21
Nitro🐘 Postgres18/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

CopilotAI left a comment

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.

Pull request overview

Updates @workflow/core hook-related e2e tests to avoid fixed sleeps by introducing a shared waitForHook() polling helper, improving reliability on slow backends/runtimes and reducing unnecessary waiting on fast ones.

Changes:

  • Added waitForHook(token, { timeoutMs, intervalMs, runId }) helper that polls getHookByToken() until the hook is available (optionally filtering by runId).
  • Replaced multiple setTimeout(5_000)-based waits with waitForHook() across hook registration/resume e2e tests.
  • Standardized one remaining direct setTimeout usage to sleep(3_000).

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

Comment threadpackages/core/e2e/e2e.test.ts Outdated
Hook-related e2e tests (hookWorkflow, hookCleanupTestWorkflow,
hookDisposeTestWorkflow, hookWithSleepWorkflow, distributedAbortController)
previously slept a fixed 5 seconds before calling getHookByToken to wait
for the hook to be registered. On slower runtimes — notably the snapshot
runtime on Vercel where each workflow round-trip is several seconds longer
than replay — that fixed budget is too tight and the test fails with
HookNotFoundError. On faster runtimes it's unnecessarily slow.
Adds a waitForHook(token, { timeoutMs, intervalMs, runId }) helper that
polls until the hook resolves or the timeout (default 30s) expires, with
an optional runId filter for token-reuse tests where eventually-consistent
backends may briefly still report a stale hook. Each hook-wait site now
uses this helper. Non-hook fixed sleeps (workflow-progress polling for
sleepingWorkflow cancel tests, payload-processing waits in
hookWithSleepWorkflow) are unchanged.
@TooTallNate
TooTallNate enabled auto-merge (squash) May 3, 2026 17:37
@TooTallNate
TooTallNate merged commit 98ca60c into mainMay 4, 2026
151 of 165 checks passed
@TooTallNate
TooTallNate deleted the e2e-wait-for-hook branch May 4, 2026 00:05
pranaygp added a commit that referenced this pull request May 4, 2026
…ignal
* origin/main:
[workbench] Add TanStack Start workbench and tests (#1875)
Atomically dedupe duplicate step_created/wait_created events in world-local (#1877)
Split tarball hosting out of docs into its own project (#1893)
Replace fixed-sleep hook waits with event-driven waitForHook helper (#1879)
pranaygp added a commit that referenced this pull request May 4, 2026
…lier-errors-followups
* origin-https/main:
[workbench] Add TanStack Start workbench and tests (#1875)
Atomically dedupe duplicate step_created/wait_created events in world-local (#1877)
Split tarball hosting out of docs into its own project (#1893)
Replace fixed-sleep hook waits with event-driven waitForHook helper (#1879)
# Conflicts:
#	pnpm-lock.yaml
VaguelySerious added a commit that referenced this pull request May 4, 2026
Conflicts resolved:
* `packages/core/e2e/e2e.test.ts` (PR #1879 vs. V2 hookDispose helper)
Drop the locally-defined `waitForHook(expectedRunId)` shadow in the
hookDisposeTestWorkflow test in favor of the new top-level
`waitForHook(token, { runId })` API merged from main. Keep V2's
event-driven `waitForHookDisposal()` helper, which is stricter than
main's `await sleep(3_000)` (it polls `getHookByToken` for the
HookNotFoundError signal rather than waiting a fixed interval).
* `packages/world-local/src/storage/events-storage.ts` (PR #1877 vs.
V2 per-step async mutex)
Both branches were closing race conditions in the local world's
step lifecycle. PR #1877 adds filesystem-level O_CREAT|O_EXCL locks
for `step_created` and `wait_created`; the V2 branch already wraps
step lifecycle events in an in-process `withStepLock` mutex. They
compose: the mutex serializes within a single Node process; the
filesystem lock additionally protects against cross-process races
(multiple pnpm workers, redelivered queue messages). Resolution
takes V2's mutex wrap as the base and patches in main's two
`writeExclusive` claims at the start of the `step_created` and
`wait_created` handlers, with comments noting the dual-layer
guarantee.
`packages/core/e2e/utils.ts` auto-merged: V2's nextjs-webpack +
all-Vercel source-map carve-outs preserved alongside main's
`tanstack-start` addition to `hasWorkflowSourceMaps`.
Verified locally: `@workflow/core` and `@workflow/world-local`
typecheck clean; all 343 world-local unit tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ziyak97 pushed a commit to ziyak97/workflow that referenced this pull request May 4, 2026
…ercel#1879)
Hook-related e2e tests (hookWorkflow, hookCleanupTestWorkflow,
hookDisposeTestWorkflow, hookWithSleepWorkflow, distributedAbortController)
previously slept a fixed 5 seconds before calling getHookByToken to wait
for the hook to be registered. On slower runtimes — notably the snapshot
runtime on Vercel where each workflow round-trip is several seconds longer
than replay — that fixed budget is too tight and the test fails with
HookNotFoundError. On faster runtimes it's unnecessarily slow.
Adds a waitForHook(token, { timeoutMs, intervalMs, runId }) helper that
polls until the hook resolves or the timeout (default 30s) expires, with
an optional runId filter for token-reuse tests where eventually-consistent
backends may briefly still report a stale hook. Each hook-wait site now
uses this helper. Non-hook fixed sleeps (workflow-progress polling for
sleepingWorkflow cancel tests, payload-processing waits in
hookWithSleepWorkflow) are unchanged.
TooTallNate added a commit that referenced this pull request May 5, 2026
Resolve conflicts:
- packages/core/src/serialization/* (workflow.ts, step.ts, client.ts,
codec-devalue.ts, errors.ts, common.ts): take main's version (post-#1849
SerializationError + post-#1851 first-class Error subclass reducers).
- packages/core/src/serialization/types.ts: take main's per-Error-subclass
payload shapes; re-add GZIP/ZSTD format prefixes from snapshot-runtime.
- packages/core/src/serialization.ts: take main's V2 helpers
(dehydrateStepError, hydrateStepError, dehydrateRunError, hydrateRunError,
getWorldLazy import).
- packages/core/src/runtime.ts: take main's V2 inline-replay loop +
step-executor + memoizeEncryptionKey + dehydrateRunError patterns; layer
back snapshot dispatch (useSnapshotRuntime + runWorkflowWithSnapshots)
before the V2 main replay loop, after run_started setup.
- packages/core/src/runtime/start.ts: take main's getWorldLazy; keep
snapshot's getWorkflowRuntimeFromEnv usage.
- packages/world-local/src/storage/index.ts: take main's local-var refactor
+ LocalStorage type; layer back snapshots storage entry.
- packages/world-local/src/storage/events-storage.ts: take main's version
(already includes #1877 dedup atomicity and #1851 Uint8Array passthrough).
- packages/world-postgres: take main's tightened EntityConflictError gate
(constraint name match) and waitCreated test assertion. Renumber
snapshot's 0010_add_snapshots_table.sql to 0012; drop branch's duplicate
0011_add_events_entity_creation_unique_index.sql in favor of main's 0010
with dedup CTE.
- packages/core/e2e/e2e.test.ts: take main's #1879 waitForHookDisposal.
- .github/workflows/tests.yml: take main's runLabel/artifactSuffix naming
scheme; keep snapshot's WORKFLOW_RUNTIME env var; take main's Windows
job structure.
- scripts/create-test-matrix.mjs: extend the runtime cross-product to
fold runtime into runLabel and artifactSuffix so artifacts/job names
remain unique.
Snapshot dispatch is now layered on top of V2: when a workflow message
arrives and the run's runtime mode is 'snapshot', runtime.ts delegates
to runWorkflowWithSnapshots and returns. The V2 inline-replay loop and
inline executeStep path remain in place for replay-mode runs and for
inline step execution from background-step deliveries (snapshot mode
will also re-route step queueing to the unified workflow queue in a
follow-up commit so steps hit V2's executeStep instead of stepEntrypoint).
Sign up for freeto 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

@TooTallNate@VaguelySerious