cloudflare / cloudflare/cloudflare-docs

Cross-Process Communication breaks when specifying environment

Open
#27,910 5 comments 0 reactions 1 assignee Claimed by @korinne View on GitHub
bug documentation product:workers stale
Dominant language
MDX
Stars
5.2k
Forks
16.7k
Avg merge
2d 6h
Merged PRs (30d)
337

Description

### What versions & operating system are you using?

System:
OS: macOS 15.5
CPU: (8) arm64 Apple M2
Memory: 512.47 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.18.1 - /Users/eric/.nvm/versions/node/v20.18.1/bin/node
npm: 10.8.2 - /Users/eric/.nvm/versions/node/v20.18.1/bin/npm

wrangler 4.45.0
@cloudflare/vite-plugin 1.13.15

### Please provide a link to a minimal reproduction

https://github.com/tenpaiyomi/cf-multi-worker-cross-process-bug

### Describe the Bug

I initially was trying to get service bindings working through the vite plugin and the `auxiliaryWorkers` config, coupled with the wrangler configuration for service bindings, with no luck, so upon researching more I found that cross-process communication was recently introduced and figured I'd try it.

I have 1 worker that is started via a standard `vite --mode development` and it works fine. If I start a separate worker with `wrangler dev -c workers/exchange-parser-worker/wrangler.toml`, then from my primary worker I can trigger the second, however it is missing my environment variables for development. If I then start the secondary worker with `wrangler dev -c workers/exchange-parser-worker/wrangler.toml -e development`, it starts and I see that it loads all the environment variables from my `.env.development` file, however when I attempt to trigger it from the primary worker I now get:

```
3:58:29 PM [vite] Internal server error: Cannot access "getSessionIdsMissingExchanges" as we couldn't find a local dev session for the "MissingExchangesSessionProcessing" entrypoint of service "exchange-parser-worker" to proxy to.
at Object.fetch (/Users/eric/Development/[redacted]/sync-cloud/worker/index.ts:45:20)
at null. (/Users/eric/Development/[redacted]/node_modules/@sentry/cloudflare/src/request.ts:108:27)
at maybeCaptureError (workers/runner-worker.js:43:10)
```

To ensure this was not some configuration issue or so, I removed all the environment variables and development specific configuration from the `wrangler.toml` file, however the end result was the same. If I specify an environment, then cross-process communication seems to break. To verify that this was not explicitly just a wrangler/vite scenario, I also tried the test between wrangler/wrangler.

I started my primary worker using `wrangler dev -c sync-cloud/wrangler.toml -e development` and saw the appropriate binding for my service stating it was not connected. From there, I started my secondary worker with just `wrangler dev -c workers/exchange-parser-worker/wrangler.toml`, noting that it did not load my environment variables but DID reflect that it was connected to my primary worker. I then stopped it, saw that it disconnected, and then started again with `wrangler dev -c workers/exchange-parser-worker/wrangler.toml -e development` and noted that it DID load my environment variables, but DID NOT reflect as being connected to my primary worker.

To further verify that this was *explicitly* due to specifying the environment and not due to any of my settings, I renamed my `.env.development` to just `.env`, and moved all my `env.development` configuration options in my `wrangler.toml` file to be all top level. I then once again started my worker with `wrangler dev -c workers/exchange-parser-worker/wrangler.toml` and confirmed that it DID load all my environment variables and bindings, and it DID also show as being connected.

So the common and consistent factor here for the secondary worker not connecting to a service binding each time was simply specifying the environment when starting it with `wrangler dev`

### Please provide any relevant error logs

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.