feat(miniflare,wrangler): cross-worker workflow bindings via dev registry#13863
Merged
petebacondarwin merged 3 commits intoJun 2, 2026
Merged
Conversation
🦋 Changeset detectedLatest commit: c6b104a The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 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
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
@cloudflare/wrangler-bundler
commit: |
aslakhellesoy
added a commit
to badreddinesaadioui/sveltekit-add-worker-exports
that referenced
this pull request
May 24, 2026
The HTTP-bridge fallback for workflow bindings now lives entirely under src/bridge/, with the substantive bridge logic in a real compiled TypeScript file (bridge/dev-handler.ts) instead of a string template — the cache wrapper now imports `createBridgeFetch` from a new `./dev-bridge` package subpath, so the only generated TS that gets written to node_modules/.cache is six lines of glue. Auto-detection happens in the runtime hook: `if (env[name]) continue` skips fake-binding injection when a real Workflow stub is present on `platform.env`. Once miniflare/wrangler ship cross-worker workflow routing (cloudflare/workers-sdk#13863), real stubs will appear and the bridge becomes a transparent no-op. When the upstream PR lands, deleting the bridge is mechanical: delete src/bridge/, drop the setupBridge call in src/index.ts, collapse src/hooks.ts to a no-op handle, drop the ./hooks and ./dev-bridge subpath exports. Each affected file has a comment pointing at the same removal recipe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When a workflow binding has a `scriptName` that doesn't match a worker in the local Miniflare instance, mark it `external` and have the workflows plugin point the engine's USER_WORKFLOW binding at the existing dev-registry-proxy worker's `ExternalServiceProxy` entrypoint (via service `props`). The proxy resolves the target through the wrangler dev registry and forwards RPC method calls — including `run()` — to the workflow class running in another Miniflare instance. This mirrors the cross-worker `scriptName` support that already exists for Durable Objects (`getExternalServiceEntrypoints` / `getOutboundDoProxyClassName`); workflows just pass through `ExternalServiceProxy` rather than needing a per-(scriptName, className) generated proxy class because their engine talks to USER_WORKFLOW as a service binding. Closes cloudflare#7459.
Stop stripping every workflow binding in `getMiniflareOptionsFromConfig`; strip only those without a `script_name`. Workflows that point at another worker (`script_name` set) are handed to miniflare unchanged, which routes the engine binding through the dev-registry-proxy when the target worker is registered in the wrangler dev registry. Without `script_name` the workflow's engine still has nowhere to dispatch USER_WORKFLOW (the proxy worker is empty), so we keep the existing strip + warn behaviour for that case — just narrow the warning text to "...without a script_name:". Pairs with the corresponding miniflare change in this PR.
0ee93a5 to
2c4f203
Compare
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers |
petebacondarwin
approved these changes
Jun 2, 2026
workers-devprod
approved these changes
Jun 2, 2026
workers-devprod
left a comment
Contributor
There was a problem hiding this comment.
Codeowners reviews satisfied
Merged
aslakhellesoy
added a commit
to oselvar/sveltekit-add-worker-exports
that referenced
this pull request
Jun 4, 2026
wrangler 4.98.0 (cloudflare/workers-sdk#13863) fixes cross-worker workflow routing in getPlatformProxy, so workflow bindings now reach the sidecar via script_name like Durable Objects do. The HTTP bridge fallback, service binding, and runtime hook that synthesised Workflow-shaped objects on platform.env are no longer needed: - Delete src/bridge/ (dev-handler, runtime-hook, setup) and the ./dev-bridge package export. - Point the dev config's main directly at options.entryPoint instead of the generated cache wrapper. - Reduce src/hooks.ts to a no-op passthrough (kept for backwards compatibility with users already wiring it into hooks.server.ts). - Update README to drop the bridge wiring section and example to drop hooks.server.ts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
aslakhellesoy
added a commit
to oselvar/sveltekit-add-worker-exports
that referenced
this pull request
Jun 6, 2026
The `/hooks` subpath exported a no-op `Handle` kept for backwards compatibility after wrangler 4.98.0 fixed cross-worker workflow routing in getPlatformProxy (cloudflare/workers-sdk#13863). No longer needed. BREAKING CHANGE: `import { handle } from '@oselvar/sveltekit-add-worker-exports/hooks'` no longer resolves. Remove the import from your `src/hooks.server.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
3 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.
Workflow bindings get stripped from
getPlatformProxy()because miniflare can't run a workflow whose engine lives in another worker. That's fine inside a self-containedwrangler dev, but it kills the split-process model thatadapter-cloudflare(SvelteKit, Remix) uses in dev — the user's+server.tsruns in Vite, the workflow class runs in a wrangler sidecar, andplatform.env.MY_WORKFLOW.create(...)becomesundefined.create(...).DOs already work in this setup via
script_namecross-worker routing through the dev registry. This PR adds the same for workflows.scriptNamedoesn't refer to a local worker, route the engine'sUSER_WORKFLOWbinding through the existingExternalServiceProxyon the dev-registry-proxy worker. Same plumbing DOs use; no new proxy class needed because workflows talk to USER_WORKFLOW as a service binding.getPlatformProxy()stops stripping workflows that have ascript_name(it still strips local ones — the engine has nowhere to go for those).Tested with a SvelteKit example end-to-end:
platform.env.BOT_WORKFLOW.create(...)from a +server.ts now returns a real instance, runs in the sidecar, and a step inside the workflow can call back to a DO and reply over a WebSocket. Unit test added indev-registry.spec.tsmirrors the existing cross-worker DO tests.Closes #7459.