[Miniflare] Cross-worker Durable Object proxy drops ctx.id.name for IDs created with idFromName()
What versions & operating system are you using?
- Wrangler: 4.127.1
- Miniflare: 5.20260828.0-alpha
- workerd: 1.20260828.1
- Node.js: 24.18.0
- OS: Linux x86_64, kernel 5.15
- compatibility date: 2026-08-01
Please provide a link to a minimal reproduction
https://github.com/HemeraOne/miniflare-cross-worker-do-name-repro
Describe the Bug
When a Durable Object is addressed through a cross-worker script_name binding in local
development, the calling Worker creates the ID using idFromName("demo"), and id.name is
correctly "demo". Inside the target Durable Object, however, ctx.id.name is undefined.
The reproduction runs the target and caller as separate wrangler dev processes so the binding
uses the local dev registry proxy.
Steps:
- Clone the reproduction and run
npm install. - Run
npm run dev:targetin one terminal. - Run
npm run dev:callerin another terminal. - Run
curl http://localhost:8787.
Observed response:
{
"callerName": "demo",
"targetIdentity": {
"id": "b1ccfce0b5e6b4bbf20bf9b3deab56d6fde0a93191910bee462c390e7f925ff3",
"name": null
}
}Expected: targetIdentity.name is "demo", matching callerName.
The Durable Object ID documentation states that ctx.id.name is available when the caller uses
idFromName() or getByName():
https://developers.cloudflare.com/durable-objects/api/id/#name
The current proxy implementation appears to forward only the hexadecimal ID to getActor():
This passes this.ctx.id.toString() across the process boundary. Reconstructing the target actor
from that value appears to lose the logical name, consistent with the documented behavior of
idFromString().
The discrepancy breaks libraries that correctly rely on native ctx.id.name for named Durable
Objects. For example, Agents SDK 0.22 reports that it cannot determine the Durable Object name even
though the caller used getAgentByName(), which addresses the object through idFromName().
Relevant error logs
The raw Durable Object reproduction returns name: null as shown above. With Agents SDK 0.22 this
surfaces as:
Agent could not determine its Durable Object name. Address it with idFromName() or getByName().Source: cloudflare/workerd