cloudflare / cloudflare/workerd

[Miniflare] Cross-worker Durable Object proxy drops ctx.id.name for IDs created with idFromName()

Open Beginner friendly
#7,286 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
8.7k
Forks
739
Avg merge
2d 20h
Merged PRs (30d)
174

Description

## 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:

1. Clone the reproduction and run `npm install`.
2. Run `npm run dev:target` in one terminal.
3. Run `npm run dev:caller` in another terminal.
4. Run `curl http://localhost:8787`.

Observed response:

```json
{
"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()`:

https://github.com/cloudflare/workers-sdk/blob/main/packages/miniflare/src/workers/core/dev-registry-proxy-shared.worker.ts#L214-L220

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:

```text
Agent could not determine its Durable Object name. Address it with idFromName() or getByName().
```

Contributor guide

Open the contributing guide

Research direction

Run the linked reproduction with npm install, npm run dev:target, npm run dev:caller, and curl http://localhost:8787. Then inspect packages/miniflare/src/workers/core/dev-registry-proxy-shared.worker.ts around lines 214-220 and trace the actor identity passed across the proxy; done means the target response preserves name "demo" for an idFromName("demo") call.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
distributed-systems
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.