`placement` in production misroutes `ctx.exports.<WorkerEntrypoint>.fetch()` to main `fetch` (RPC still works)

[alexeichhorn]

Summary

I have a minimal reproducible case where ctx.exports.<WorkerEntrypoint>.fetch(...) is misrouted in production when placement is enabled.

• RPC method call on the same entrypoint still works.
• Local wrangler dev behaves correctly.
• Production behaves correctly again if placement is removed.

This appears to be a runtime routing issue triggered by placement in production.

Repro links

• Minimal repro repo:
  https://github.com/alexeichhorn/cloudflare-ctx-exports-bug-reproduction
• Live deployed repro:
  https://cloudflare-ctx-exports-bug-reproduction.white-meadow-a345.workers.dev/probe
• Community thread:
  https://community.cloudflare.com/t/ctx-exports-workerentrypoint-fetch-misrouting-when-placement-is-enabled-rpc-still/899525

What the repro does

/probe calls the same WorkerEntrypoint in two ways:

1. ctx.exports.OutboundProbe({}).someOtherFunc() (RPC)
2. ctx.exports.OutboundProbe({}).fetch(new Request(...)) (fetch)

Expected behavior

Call (2) should execute OutboundProbe.fetch and return text starting with FROM_OUTBOUND_CLASS.

Actual behavior (production with placement enabled)

• Call (1) works and returns FROM_RPC_METHOD ...
• Call (2) is routed to main index.fetch and returns FROM_INDEX_DEFAULT

Current sample output from live repro:
{"directRpc":"FROM_RPC_METHOD mode=no-props","directFetchText":"FROM_INDEX_DEFAULT","note":"Direct ctx.exports fetch should hit OutboundProbe.fetch and start with FROM_OUTBOUND_CLASS."}

Isolation results

• Local wrangler dev: correct behavior.
• Production + placement enabled: misrouting reproduced.
• Production + placement removed: correct behavior.
• Changing placement region still reproduces (not region-specific).

Environment

• wrangler: 4.68.1
• typescript: 5.9.3
• compatibility_date: 2026-02-25
• Placement config currently:
  "placement": { "region": "aws:eu-central-1" }

Fresh production request IDs

(maybe helpful)

1. date: Sun, 01 Mar 2026 17:49:36 GMT, cf-ray: 9d59ffcbc99429a7-ZRH
2. date: Sun, 01 Mar 2026 17:49:37 GMT, cf-ray: 9d59ffd34eca7a85-ZRH
3. date: Sun, 01 Mar 2026 17:49:38 GMT, cf-ray: 9d59ffda0dcab159-ZRH

[nathanschram]

I think this is a platform-layer routing issue with Smart Placement rather than anything in your code - your repro is clean and the setup looks correct.

From reading the workerd source, the entrypoint dispatch itself works fine - WorkerEntrypoint::request() in worker-entrypoint.c++ resolves the entrypoint name correctly, and LoopbackServiceStub in export-loopback.h routes through the subrequest channel as expected. The issue looks like it's in the production placement routing layer that sits above this.

The CF docs note that placement "only affects the execution of fetch event handlers", and the RPC reserved methods docs say .fetch() has "Fetch API semantics, not RPC semantics". So when ctx.exports.OutboundProbe({}).fetch(request) fires, the .fetch() call gets dispatched as a Fetch API request through the subrequest channel. The placement routing layer likely intercepts this fetch dispatch and loses the entrypoint name metadata, falling back to the default fetch handler. RPC methods bypass placement entirely (documented behaviour), which is why .someOtherFunc() works fine.

As a workaround until this gets fixed, you could replace .fetch() with a custom RPC method that returns a Response:

export class OutboundProbe extends WorkerEntrypoint {
  async probeRequest(url: string): Promise<Response> {
    return fetch(url);
  }
}

// In the caller:
const response = await ctx.exports.OutboundProbe({}).probeRequest(targetUrl);

Since RPC methods aren't subject to placement routing, this should sidestep the issue. It's not ideal but it should unblock you while the placement team looks at preserving entrypoint targeting metadata during fetch forwarding.

Let me know if that workaround sorts it out for your use case.

[alexeichhorn]

Thank you for the response. I'm happy that this is being fixed.
Your workaround is actually what I also end up doing, and it is working not too badly. Thank you.