[core] [world] Fix community world E2E tests broken by specVersion bump#1658
Merged
VaguelySerious merged 3 commits intomainfrom Apr 8, 2026
Merged
[core] [world] Fix community world E2E tests broken by specVersion bump#1658VaguelySerious merged 3 commits intomainfrom
VaguelySerious merged 3 commits intomainfrom
Conversation
…URRENT bump SPEC_VERSION_CURRENT was bumped to 3 in #1627, but community worlds (Redis, MongoDB) depend on @workflow/world v4.1.0-beta.2 where SPEC_VERSION_CURRENT is 2. Their requiresNewerWorld() check rejects runs with specVersion 3, causing every workflow to 500 and the E2E tests to time out. Fix: revert SPEC_VERSION_CURRENT to 2 (safe baseline all worlds handle) and add a `specVersion` property to the World interface so individual worlds can declare support for higher versions. world-vercel sets specVersion to 3, enabling CBOR queue transport and resilient start without breaking community worlds. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 67f2d9c The changes in this PR will be included in the next version bump. This PR includes changesets to release 20 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (65 failed)mongodb (4 failed):
redis (3 failed):
turso (58 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
The previous approach (reverting to 2) broke E2E Local Dev/Prod/Postgres tests because world-local also uses requiresNewerWorld() which rejects specVersion > SPEC_VERSION_CURRENT. Instead: keep SPEC_VERSION_CURRENT=3, add specVersion property to all first-party worlds, and fall back to SPEC_VERSION_SUPPORTS_EVENT_SOURCING (2) in start() when the world doesn't declare its version (community worlds). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TooTallNate
approved these changes
Apr 8, 2026
Member
TooTallNate
left a comment
TooTallNate
left a comment
There was a problem hiding this comment.
Good fix for the community world breakage. The approach is sound: add specVersion to the World interface so worlds can declare their capability, and have start() use that instead of the global SPEC_VERSION_CURRENT constant.
What I verified
The core problem: Community worlds (Redis, MongoDB) depend on @workflow/world v4.1.0-beta.2 where SPEC_VERSION_CURRENT = 2. Their requiresNewerWorld(3) check returns true and rejects runs, causing 500s.
The fix: start() fallback chain is now opts.specVersion > world.specVersion > SPEC_VERSION_SUPPORTS_EVENT_SOURCING (2). Community worlds don't set world.specVersion, so they get the safe baseline (2). Our worlds explicitly declare their version:
world-vercel:SPEC_VERSION_SUPPORTS_CBOR_QUEUE_TRANSPORT(3) — enables CBOR transport + resilient startworld-local:SPEC_VERSION_CURRENT(3)world-postgres:SPEC_VERSION_CURRENT(3)
Health check specVersion: Both handleHealthCheckMessage and withHealthCheck now pass through worldSpecVersion from getWorldHandlers(), so the health check response reflects the actual world's version rather than the global constant. This is correct — the health check is used by the CLI to determine which queue transport to use (#1629).
Event-level SPEC_VERSION_CURRENT usage: The many SPEC_VERSION_CURRENT references in step-handler.ts, runtime.ts, suspension-handler.ts, etc. are for event specVersions created during runtime execution (not run creation). These are fine — by the time the code runs, the deployment has already started and the world is the local instance.
Clarification on PR description: The description says "Reverts SPEC_VERSION_CURRENT to 2" but the constant is NOT changed — it's still 3. The change is that start() no longer defaults to SPEC_VERSION_CURRENT when the world doesn't declare its version. The description should be updated to avoid confusion.
Non-blocking
-
The
World.specVersionJSDoc says "When omitted, runs default toSPEC_VERSION_CURRENT(the lowest version all worlds are expected to support)" — butSPEC_VERSION_CURRENTis 3, and the actual fallback instart.tsisSPEC_VERSION_SUPPORTS_EVENT_SOURCING(2). The doc comment is misleading. -
world-localandworld-postgresboth setspecVersion: SPEC_VERSION_CURRENT(3), which means they declare support for CBOR queue transport. This is fine since they don't use VQS and their queue implementations handle arbitrary payloads — but it's semantically a bit loose since CBOR transport is a VQS concept.
LGTM.
| * features (e.g., CBOR queue transport) are enabled automatically. | ||
| * When omitted, runs default to `SPEC_VERSION_CURRENT` (the lowest | ||
| * version all worlds are expected to support). | ||
| */ |
Member
There was a problem hiding this comment.
Non-blocking: The JSDoc says "When omitted, runs default to SPEC_VERSION_CURRENT (the lowest version all worlds are expected to support)" — but SPEC_VERSION_CURRENT is 3, not 2. The actual fallback in start.ts is SPEC_VERSION_SUPPORTS_EVENT_SOURCING (2). This comment will confuse anyone reading the interface.
Suggested:
/**
* The highest spec version this World supports.
*
* When set, `start()` creates runs at this version so world-specific
* features (e.g., CBOR queue transport) are enabled automatically.
* When omitted, runs default to `SPEC_VERSION_SUPPORTS_EVENT_SOURCING` (2),
* the safe baseline that all worlds — including community worlds on
* older @workflow/world versions — are expected to handle.
*/
3 tasks
ghost
mentioned this pull request
2 tasks
VaguelySerious
added
the
backport-stable
ghost
pushed a commit
that referenced
this pull request
Apr 16, 2026
…mp (#1658) Signed-off-by: Peter Wielander <mittgfu@gmail.com>
|
Backport to To resolve manually: git fetch origin stable
git checkout stable
git cherry-pick a5c90cefba01070aa4bc12a696334ee4c1061f92
# Fix conflicts, then:
git cherry-pick --continue
git push origin stable |
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SPEC_VERSION_CURRENTwas bumped to 3 in [core] [world] Gate CBOR queue transport on specVersion #1627, but community worlds (Redis, MongoDB) depend on@workflow/worldv4.1.0-beta.2 whereSPEC_VERSION_CURRENTis 2. TheirrequiresNewerWorld()check rejects runs with specVersion 3, causing every workflow execution to return 500 and the E2E community world tests to time out after 30 minutes.SPEC_VERSION_CURRENTto 2 (safe baseline all worlds handle) and adds aspecVersionproperty to the World interface so individual world implementations can declare support for higher versions.world-vercelsetsspecVersion: 3, preserving CBOR queue transport and resilient start without breaking community worlds.Test plan
🤖 Generated with Claude Code