Dispatch Namespace Binding Missing in Durable Object `env` During `wrangler dev` Simulation When Other DO Bindings Exist

[marcoaleixo]

Which Cloudflare product(s) does this pertain to?

Wrangler

What versions & operating system are you using?

wrangler 4.13.1, node v23.7.0, sequoia 15.4.1 (24E263)

Please provide a link to a minimal reproduction

No response

Describe the Bug

Hey!

I'm running into an issue with wrangler dev where Dispatch Namespace bindings defined in my wrangler.toml aren't showing up in the env object passed to my Durable Object constructors during local simulation.

My Setup:

1. A main Worker (src/index.ts).

2. Two Durable Object classes: DO_A (src/durable-objects/do_a.ts) and DO_B (src/durable-objects/do_b.ts).

3. Another Worker service (user-worker) which is the target for a Dispatch Namespace.

4. My wrangler.toml looks something like this:

   name = "binding-test"
   main = "src/index.ts"
   compatibility_date = "2024-04-05"
   
   [[durable_objects.bindings]]
   name = "DO_A"
   class_name = "DO_A"
   
   [[durable_objects.bindings]]
   name = "DO_B"
   class_name = "DO_B"
   
   [[dispatch_namespaces]]
   binding = "DISPATCH_NS"
   namespace = "user-worker" # Name of the target worker service
   

Expected Behavior:

When I run wrangler dev and an instance of DO_A gets created, I expect the env object passed to its constructor to contain all the bindings defined globally in wrangler.toml – specifically DO_A, DO_B, and DISPATCH_NS. I should then be able to access this.env.DISPATCH_NS from within my DO_A instance (e.g., in its Workspace or alarm methods).

Actual Behavior:

1. When I log Object.keys(env) inside the DO_A constructor, it only shows the keys for the Durable Object bindings: DO_A, DO_B.

   // In DO_A constructor
   constructor(state: DurableObjectState, env: Env) {
       this.env = env;
       // This only logs "DO_A, DO_B"
       console.log(`DO_A Constructor: Received env keys:`, Object.keys(env).join(', '));
       // ...
   }
   

2. The key for the Dispatch Namespace binding (DISPATCH_NS) is missing from the env object.
3. Consequently, any code inside DO_A that tries to access this.env.DISPATCH_NS (like this.env.DISPATCH_NS.fetch(...)) fails locally with an error like "TypeError: Cannot read properties of undefined (reading 'fetch')".
4. I've double-checked my wrangler.toml syntax and it seems correct.
5. I also tried commenting out the DO_B binding, and DISPATCH_NS was still missing from the env passed to DO_A (the keys were just DO_A).

Impact:

This prevents me from testing any Durable Object logic locally that needs to interact with another Worker via a Dispatch Namespace. My code works correctly when deployed, but the local development workflow is broken for this use case.

Steps to Reproduce:

1. Create a project with a main Worker, two DO classes (DO_A, DO_B), and a separate target Worker (user-worker).
2. Configure wrangler.toml as shown above, binding DO_A, DO_B, and DISPATCH_NS (pointing to user-worker).
3. In the DO_A constructor, log Object.keys(env).
4. In some method of DO_A (like Workspace or alarm), try to call this.env.DISPATCH_NS.fetch(...).
5. Run wrangler dev.
6. Trigger an action that instantiates DO_A and calls the method from step 4.
7. Observe that the constructor log is missing DISPATCH_NS and the attempt to access this.env.DISPATCH_NS throws an error.

( yeah I used LLM to rewrite the description but I promisse that I wrote most of it 😅 )

Error logs

✘ [ERROR] A_DO 22e3021f-4fd8-41d7-bba5-a41ad65273fe: DISPATCH_NS binding missing! Cannot trigger worker.

[marcoaleixo]

I thought for a second that deploying to cloudflare fixed the issue, but this is happening in production as well.

[emily-shen]

Hiya, so this is expected in dev, where dispatch namespaces are not supported. I did try and reproduce this in production though, and i do seem to be getting the dispatch namespace binding when i deploy. Would you be able to provide a link to a repo with a minimal reproduction so we can test and help debug?

[penalosa]

We haven't heard from you in while so I'm going to close this issue for now. If you're still running into problems feel free to open a new issue with more details and we can investigate further.