bug: DurableObjectId::id.name doesn't work

(maybe this is a feature request?)

When creating a durable object with .idFromName(name), I would expect this.ctx.id.name inside a durable object. to reflect the same. The types imply that it should it work, was it just missed?

We use this name extensively, but currently have to hack it in by passing it in with an explicit method, but it's super cumbersome to do so without a bunch of hacks and making sure it's passed before any subsequent requests/methods are called. It would simplify a lot if workerd/workers/wrangler could provide it by default. Please and thank you!

The "hack"/workaround we have also doesn't work for alarms, so fixing this would fix that bug as well.

This bothers me too, but I can't figure out how to make it work. The thing is, you are allowed to do:

let id = ns.idFromName("foo");
let id2 = ns.idFromString(id.toString());
ns.get(id2);

In this case, we've lost the name, because id.toString() only encodes the hex ID, not the name. How do we support this?

Moreover, for alarms, where does the name get stored? Does everything in the system which stores a DO ID need to store the name too, or do we implicitly store the name in the DO's own metadata?

Storing it in the metadata seems highly preferable (I guess it would get initialized the first time a name-bearing ID is used?), but then this gets weird when you consider that DOs are implicitly deleted if they shut down while their storage is empty. So the name has to be forgotten at that point. But only if the storage is empty? Is that weird?

I was meaning to ask, why is that pattern even around? I kinda remember it being in the docs, but can't find it there anymore (and rewrote some of my non-released code to not have that intermediate step anymore).

I think we can simply message the conditions under which that name will exist.

It won't exist if using newUniqueId()
it won't exist if using the above pattern (or rather, it'll return the hex id instead)
it's only ns.get(ns.idForName(...)). This might exclude any existing DOs that rewrite to this pattern, but that's a hit we should take

I guess it would get initialized the first time a name-bearing ID is used?)

Yes

his gets weird when you consider that DOs are implicitly deleted if they shut down while their storage is empty. So the name has to be forgotten at that point. But only if the storage is empty? Is that weird?

Oh hmm. Does that mean it won't be available in alarms? In which case, can we store the name everywhere the ID is stored?
Or does setting an alarm mean that storage isn't empty? In which case, it's fine, since it'll get the name again when it comes back to life.

The next alarm time counts as a stored value, so when an alarm is present then storage is not empty.

There are other built-in features planned which are likely to store hex IDs and where we wouldn't really want those systems to have to think about storing names alongside them.

But perhaps we can be reasonably confident that future features similar to alarms that store a hex ID only are never going to be waking up an empty object? And therefore the only way an object might not know its name is if application code wakes up an empty object by ID? Maybe that's OK?

Another weird issue: Technically someone could be passing in a multi-megabyte string as a name, which works fine if it's just getting hashed down but not so fine if we have to transmit that name over the network implicitly. Maybe there's some threshold at which we refuse to automatically store the name for them?

And therefore the only way an object might not know its name is if application code wakes up an empty object by ID? Maybe that's OK?

Yeah, I think that's ok too

Maybe there's some threshold at which we refuse to automatically store the name for them?

Also ok! Maybe we disallow giant names at all, unless there's a usecase I don't know.

@joshthoward

for when @joshthoward is back, maybe a good first issue for July onboarding folks

fix: workaround for cloudflare/workerd#2240

We have a common pattern in Prisma where we name DOs based on some value that we also need inside the DO. One such example is our tenant ID which is a value created by newUniqueId() of one DO initially and then used to as the name of other DO classes that are spawned from that tenant (often from additional workflows). Those spawned DOs often need their tenant ID value to do their work, so we pass it in on an initialization call and put it into storage. This is a bit awkward as we need to forward the tenant ID with any calls into the spawned DO just in case it is the first time it is being initialized for that tenant.

RpcTarget is useful here as we can improve the interaction with these DOs by having a single RPC method for initializing with a tenant ID (or other context) which returns an RpcTarget implementation containing the actual operations. This ensures that we provide the appropriate initialization context while not having to awkwardly include it as part of every method or HTTP request on the DO. I suppose it's the same end result, though it feels much nicer to work with.

@boristane

Myself and @boristane just ran into this issue.

It's really confusing and breaks the abstraction a DO can provide when doing multi-tenancy using a durable object.

It would be excellent to be able to get id in DO instances, we currently workaround this too for Workflows

ns.idFromName("foo")

this does a lookup to get the hex id from "foo" since any worker calling it needs to get the same hex id. Can a DO do a reverse lookup on instantiation (or only in the getter for ctx.id.name since many do not use it) to see if there is any name associated with it's hex id?

this does a lookup to get the hex id from "foo" since any worker calling it needs to get the same hex id.

It actually doesn't do a lookup. It uses a cryptographic hash function to generate the ID based on the name.

Can a DO do a reverse lookup

No, because hash functions are one-way.

@rtbenfield

I'm encountering a similar issue to what @rtbenfield described earlier. In our multi-tenant event storage system, we use the tenant ID as the name to facilitate communication between multiple Durable Objects across different namespaces.
Currently, we rely on a top-level "management" Durable Object to store and retrieve the mapping of IDs for other Durable Objects. This approach requires additional roundtrips, which adds complexity and latency to our system.

Questions:

Are there any updates or planned features that would allow us to access the Durable Object's name directly from within the object?
Is using a management Durable Object to handle ID mappings a common pattern?
What alternative workarounds have you found effective in similar scenarios?

I can't make any promises for the team, but iiuc getting the name inside a durable object instance (with some constraints) is on the roadmap.
Using a management Durable Object (or even, just a database table) to handle mappings is indeed common. For example, a database that holds chatrooms that have already been created so they can be enumerated and listed before a user enters one of them.
An alternative is to read the name from the url of the first request (or when using plain rpc, expose an "initialise" function that gets executed before anything else) and store the name of the DO in .storage.

We are also interested on this.
The company I work on is facing observability issues since we cannot "log" the name from within the durable object without hacks.

IMHO it should be ok to save it as part of the metadata of the DO, even when it gets lost if the storage is empty. Since the name -> id mapping is done through a cryptographic hash function, it will always result in the same id.

Please check #6101

fix: implement session ID persistence with Cloudflare Workers workaround

fix: session ID persistence with Cloudflare Workers workaround (#21)

this seems to have been fixed... is that expected? cloudflare/workers-rs#959 👀

looks like #6421 did the trick

@maxmcd

@maxmcd if this is fully fixed (local and prod) you should close this issue. :)

@kentonv

@kentonv yep! Just confirmed this is working in the latest wrangler and it has been out in production for a few weeks now. ctx.id.name now works inside a Durable Object 🙂.

There are some constraints that are worth considering that are noted in the docs: https://developers.cloudflare.com/durable-objects/api/id/#name

feat: Trajectory + Eval Platform + Scorer library + product surfaces

@maxmcd

FYI - I'm continuing to see this error code cc @maxmcd

Remove brute-force workaround for DurableObject name lookup (#257)

Document that DurableObjectId::name is passed through to the object (#…

Navigation Menu

Repository navigation

bug: `DurableObjectId::id.name` doesn't work #2240

23 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

bug: DurableObjectId::id.name doesn't work #2240

Description

Activity

threepointone commented on Jun 9, 2024

kentonv commented on Jun 9, 2024

threepointone commented on Jun 9, 2024

kentonv commented on Jun 9, 2024

threepointone commented on Jun 10, 2024

vy-ton commented on Jun 14, 2024

rtbenfield commented on Jun 19, 2024

Ankcorn commented on Aug 6, 2024

sidharthachatterjee commented on Aug 15, 2024

jacwright commented on Oct 15, 2024

kentonv commented on Oct 16, 2024

fernando-barroso commented on Dec 11, 2024

threepointone commented on Dec 21, 2024

romeupalos commented on Feb 14, 2025

23 remaining items

demircancelebi commented on Feb 18, 2026

connyay commented on Apr 1, 2026

kentonv commented on Apr 5, 2026

maxmcd commented on Apr 7, 2026

CharlesFJWilliamson commented on Jul 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

bug: `DurableObjectId::id.name` doesn't work #2240