Support multiple workers in a single Miniflare instance #7251

penalosa · 2024-11-13T17:50:14Z

This PR allows you to run multiple workers in a single Miniflare instance, allowing for cross-service RPC without the complexities of the dev registry. To try it out, pass multiple -c flags to Wrangler: i.e. wrangler dev -c wrangler.toml -c ../other-worker/wrangler.toml. The first config will be treated as the primary worker and will be exposed over HTTP as usual (localhost:8787) while the rest will be treated as secondary and will only be accessible via a service binding from the primary worker.

Tests
- TODO (before merge)
- Tests included
- Tests not necessary because:
E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
- I don't know
- Required
- Not required because:
Public documentation
- TODO (before merge)
- Cloudflare docs PR(s): Document Wrangler's new multiworker experience cloudflare-docs#18449
- Documentation not necessary because:

changeset-bot · 2024-11-13T17:50:19Z

🦋 Changeset detected

Latest commit: 127b741

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

This PR includes changesets to release 2 packages

Name	Type
wrangler	Minor
@cloudflare/vitest-pool-workers	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 · 2024-11-14T00:42:06Z

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-wrangler-7251

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7251/npm-package-wrangler-7251

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-wrangler-7251 dev path/to/script.js

Additional artifacts:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-create-cloudflare-7251 --no-auto-update

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-cloudflare-kv-asset-handler-7251

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-miniflare-7251

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-cloudflare-pages-shared-7251

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-cloudflare-vitest-pool-workers-7251

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-cloudflare-workers-editor-shared-7251

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-cloudflare-workers-shared-7251

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12068817888/npm-package-cloudflare-workflows-shared-7251

Note that these links will no longer work once the GitHub Actions artifact expires.

[email protected] includes the following runtime dependencies:

Package	Constraint	Resolved
`miniflare`	workspace:*	3.20241106.1
`workerd`	1.20241106.1	1.20241106.1
`workerd --version`	1.20241106.1	2024-11-06

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

irvinebroque · 2024-11-15T16:42:59Z

What would we need in order for this to work without the -c flag? Something in wrangler.toml that told you the directory where the Worker that you're bound to lives?

(not saying we need to solve for it rn, just curious what the config decision we're facing is)

penalosa · 2024-11-18T14:09:29Z

What would we need in order for this to work without the -c flag? Something in wrangler.toml that told you the directory where the Worker that you're bound to lives?

Yeah, something like directory = "../other-worker/wrangler.toml" in a service binding definition would probably be enough. What I think would also be quite cool is if Wrangler detected monorepo configs (NPM/PNPM workspaces etc...) and managed to wire up workers automatically based on their service binding graph somehow, so running wrangler dev in the root of a monorepo with no additional config was enough to get this working

andyjessop · 2024-11-19T08:39:23Z

The problem with adding a new field to services in wrangler.toml is that you're then encoding this idea of a primary worker, whereas you might want to start up one of the bound workers as a primary worker to work with it directly. It might be useful also to think about a true multi-worker config, where you don't have a single primary worker, and where you can start any of the defined workers as the primary. E.g.:

{
  ...
  workers: [
    {
      name: "a",
      main: "../a/a.ts",
      bindings: { c: { "type": "worker", name: "c" } },
    },
    {
      name: "b",
      main: "../b/b.ts",
      bindings: { c: { "type": "worker", name: "c" } },
    },
    {
      name: "c",
      main: "../c/c.ts",
    },
  ]
}

# starts worker "a" at http:localhost:8787 with "c" accessible only through RPC
npx wrangler dev --worker a

# starts worker "b" at http:localhost:8787 with "c" accessible only through RPC
npx wrangler dev --worker b

# starts worker "c" at http:localhost:8787
npx wrangler dev --worker c

Multi-worker is a new paradigm for wrangler, so I would worry about adding it to the single-worker config as a patch in case we're painting ourselves into a corner. A new style config could be launched as a minor patch and would force us to tidy the unwieldy config in the code base.

(I don't say the above to derail the PR - @penalosa's solution is a neat and flexible one that doesn't tie us to any future arrangement).

andyjessop

This is amazing work - very nice observation that we essentially already have this functionality in Miniflare and it just needed hooking up 👍

Let's start the conversation on whether or not users will still want/need workers to be accessed from distinct endpoints, or if the dev registry is something we could remove entirely (perhaps in v4?).

andyjessop · 2024-11-19T08:58:51Z

packages/wrangler/e2e/multiworker-dev.test.ts

+			);
+		});
+	});
+});


Might be good to test some failure cases here.

What if a bound worker fails - do calls return the right response?

What if the primary worker fails - do the bound workers shut down correctly?

andyjessop · 2024-11-19T09:33:06Z

packages/wrangler/src/dev.ts

-						port: parseInt(url.port),
-					})
-				);
+		if (Array.isArray(configPath)) {


I feel like we could clean things up if we just treated all scenarios as multi-worker. So instead of having a separate MultiworkerRuntimeController, just modify the LocalRuntimeController to handle multi-workers, and then cast the configPath to an array in the yargs definition.

const configs = Array.isArray(configPath) ? configPath : [configPath]; // Now no need to handle the single worker case. LocalRuntimeController assumes multi. const runtime = new LocalRuntimeController(configs.length);

Or is there a reason to keep the single worker code path?

I went down this path in Merge Local & Multi controllers, but I'm starting to get a bit concerned about the potential for disrupting the normal dev flow, and I think it might end up being more complexity than it's worth. The single worker dev flow has two runtimes, remote & local, and the remote runtime doesn't (and will never) work for the multiworker use case. Because of that there's some differences in how these flows are set up (as well as the disabling of the dev registry in the multiworker flow, which involves disabling the registry as well as a change to how DOs & entrypoints are registered). It's not that much duplicated code, and I think it's actually clearer to keep them separate, and easier to reason about. What do you think?

Yeah, that sounds fair enough. Just for clarity, I assume the remote runtime will never be able to do this because it is always deploying a single worker.

I assume the remote runtime will never be able to do this because it is always deploying a single worker

Yes, the edge preview system deploys a single worker, and there's no way to hook up multiple edge preview sessions into a mesh of services¹

Footnotes

Reliably, that is. We could probably do some stuff to make this work-ish with HTTP service bindings by writing worker middleware in Wrangler to inject some headers, but that would never work with RPC or cross-worker durable objects ↩

…iniflare

zhihengGet · 2024-11-23T00:20:31Z

does this support pages , i tried wrangler pages dev .svelte/cloudfare -c ../packages/wranger.toml ... but got Pages does not support custom paths for the wrangler.toml configuration file

andyjessop · 2024-11-26T11:50:20Z

packages/wrangler/src/deployment-bundle/bundle.ts

+	if (getFlag("MULTIWORKER")) {
+		const patchedConsoleFileToInject = path.join(
+			tmpDir.path,
+			"patch-console.js"
+		);
+
+		if (!fs.existsSync(patchedConsoleFileToInject)) {
+			fs.writeFileSync(
+				patchedConsoleFileToInject,
+				fs.readFileSync(
+					path.resolve(getBasePath(), "templates/patch-console.js")
+				)
+			);
+		}
+
+		inject.push(patchedConsoleFileToInject);
+	}


Can this be done inside middleware so that we don't have to hard-code the code path in the main bundle handler?

(sorry this wasn't in the first review)

andyjessop · 2024-11-26T11:51:13Z

packages/wrangler/templates/patch-console.js

+globalThis.console = new Proxy(globalThis.console, {
+	get(target, p, receiver) {
+		if (p === "log" || p === "debug" || p === "info") {
+			return (...args) =>
+				Reflect.get(target, p, receiver)(WRANGLER_WORKER_NAME, ...args);
+		}
+		return Reflect.get(target, p, receiver);
+	},
+});


Perhaps we could wrap the logger instead of patching the console method directly.

(sorry this wasn't in the first review)

I don't think I quite know what you mean—which logger?

This is the logger I was thinking of: https://github.com/cloudflare/workers-sdk/blob/3dce3881bdaf373aa9b2e52483e340ab8193151c/packages/wrangler/src/logger.ts

That's the Wrangler logger, whereas this code is patching the console global inside a Worker, which is slightly different

…iniflare

emily-shen · 2024-11-26T19:22:19Z

does this support pages , i tried wrangler pages dev .svelte/cloudfare -c ../packages/wranger.toml ... but got Pages does not support custom paths for the wrangler.toml configuration file

@zhihengGet this does not support pages, but there is a followup to get it working with Workers + static assets

andyjessop

Really great work, thanks!

packages/wrangler/src/api/dev.ts

packages/wrangler/e2e/multiworker-dev.test.ts

packages/wrangler/src/dev.ts

emily-shen

🎉 🎉 🎉

irvinebroque · 2024-12-10T09:53:39Z

👏

Initial

2a77941

penalosa requested a review from a team as a code owner November 13, 2024 17:50

fix builds

8ce4b52

add e2e tests

b7bd589

penalosa added the e2e Run e2e tests on a PR label Nov 14, 2024

andyjessop reviewed Nov 19, 2024

View reviewed changes

emily-shen mentioned this pull request Nov 19, 2024

fix: allow assets in multiworker setup #7290

Draft

9 tasks

This was referenced Nov 20, 2024

Support multi-worker Durable Object RPC #7098

Closed

PoC: multi-worker wrangler dev #6814

Closed

penalosa added 2 commits November 21, 2024 23:56

Merge remote-tracking branch 'origin/main' into multi-worker-single-m…

fded980

…iniflare

Merge Local & Multi controllers

d632e70

andyjessop reviewed Nov 26, 2024

View reviewed changes

penalosa added 5 commits November 26, 2024 16:58

disentangle

a1bcf6f

e2e

a855111

Address review comments

4f2b070

Merge remote-tracking branch 'origin/main' into multi-worker-single-m…

206cbcd

…iniflare

Update build

36b38e3

penalosa added 2 commits November 27, 2024 14:49

fix teardown

518ea92

Create gold-pandas-yell.md

3b2dfe8

penalosa mentioned this pull request Nov 27, 2024

Document Wrangler's new multiworker experience cloudflare/cloudflare-docs#18449

Closed

andyjessop approved these changes Nov 27, 2024

View reviewed changes

CarmenPopoviciu reviewed Nov 27, 2024

View reviewed changes

packages/wrangler/src/api/dev.ts Show resolved Hide resolved

penalosa mentioned this pull request Nov 27, 2024

Support multiworker in startWorker() API #7369

Open

Merge branch 'main' into multi-worker-single-miniflare

2ffd5fc

emily-shen reviewed Nov 27, 2024

View reviewed changes

packages/wrangler/e2e/multiworker-dev.test.ts Show resolved Hide resolved

emily-shen reviewed Nov 27, 2024

View reviewed changes

packages/wrangler/src/dev.ts Show resolved Hide resolved

emily-shen reviewed Nov 27, 2024

View reviewed changes

packages/wrangler/src/dev.ts Outdated Show resolved Hide resolved

penalosa added 3 commits November 27, 2024 17:11

fix build

0000f7a

include rpc & do rpc tests

058f1ae

Remove metrics

e14865f

emily-shen approved these changes Nov 27, 2024

View reviewed changes

Remove duplicate test (tested in interactive dev fixture)

127b741

penalosa merged commit 80a83bb into main Nov 28, 2024
32 checks passed

penalosa deleted the multi-worker-single-miniflare branch November 28, 2024 14:29

workers-devprod mentioned this pull request Nov 28, 2024

Version Packages #7358

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support multiple workers in a single Miniflare instance #7251

Support multiple workers in a single Miniflare instance #7251

penalosa commented Nov 13, 2024 •

edited

Loading

changeset-bot bot commented Nov 13, 2024 •

edited

Loading

github-actions bot commented Nov 14, 2024 •

edited

Loading

irvinebroque commented Nov 15, 2024

penalosa commented Nov 18, 2024 •

edited

Loading

andyjessop commented Nov 19, 2024

andyjessop left a comment •

edited

Loading

andyjessop Nov 19, 2024

andyjessop Nov 19, 2024

penalosa Nov 22, 2024

andyjessop Nov 26, 2024

penalosa Nov 26, 2024

zhihengGet commented Nov 23, 2024 •

edited

Loading

andyjessop Nov 26, 2024

penalosa Nov 26, 2024

andyjessop Nov 26, 2024

penalosa Nov 26, 2024

andyjessop Nov 26, 2024

penalosa Nov 27, 2024

emily-shen commented Nov 26, 2024

andyjessop left a comment

emily-shen left a comment

irvinebroque commented Dec 10, 2024

Support multiple workers in a single Miniflare instance #7251

Support multiple workers in a single Miniflare instance #7251

Conversation

penalosa commented Nov 13, 2024 • edited Loading

changeset-bot bot commented Nov 13, 2024 • edited Loading

🦋 Changeset detected

github-actions bot commented Nov 14, 2024 • edited Loading

irvinebroque commented Nov 15, 2024

penalosa commented Nov 18, 2024 • edited Loading

andyjessop commented Nov 19, 2024

andyjessop left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Footnotes

zhihengGet commented Nov 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emily-shen commented Nov 26, 2024

andyjessop left a comment

Choose a reason for hiding this comment

emily-shen left a comment

Choose a reason for hiding this comment

irvinebroque commented Dec 10, 2024

penalosa commented Nov 13, 2024 •

edited

Loading

changeset-bot bot commented Nov 13, 2024 •

edited

Loading

github-actions bot commented Nov 14, 2024 •

edited

Loading

penalosa commented Nov 18, 2024 •

edited

Loading

andyjessop left a comment •

edited

Loading

zhihengGet commented Nov 23, 2024 •

edited

Loading