hmm if you're mocking you probably just need 1 bit to identify whether it is named or unique -- then for unique you randomly generate the other bits, for named you hash the provided string with whatever hash you'd like. for extra credit you could encrypt each id using a key that is specific to each namespace, and verify that the key is valid when it is used for each namespace (using that namespace's key) -- I don't think any of the specific crypto choices really matter if you're mocking though?

like if this is truly for local testing you might just want to mash together 127 bits of the namespace id with 128 random/hashed bits, so that it's easier to tell which namespace an id belongs to

cool, thanks @brett!

Hey does anyone know if there is a limit to the number of Websockets one can terminate in a Durable Object?

We don’t impose any limits, but there will be a ceiling based on what all your worker does, since it will realistically need to spend CPU time sending and receiving messages to all of the open sockets. I don’t think we’ve done any measurements at this point

okay thats good thanks

Hmm, this is a new one:

Error: Durable Object is overloaded. Requests queued for too long.

Sending a lot of requests? Or using the CPU in a DO a lot?

One sequential writer, doing a single .put(entries) on each call, called in loop, but synchronously, so really not many from a number of calls perspective - cpu of the DO is actually lower than the worker that is calling it, and well under the Bundled limit. Is it possible that

put

returns, but the data is not actually considered flushed to storage? (ie the 'requests' are underlying storage requests, not fetch requests)

also sharded across up to 16 object instances, which may be doing the writes in parallel, but I assume they are independent from each other

That shouldn’t be it, but I’m about to be at my computer. That error should mean a request sat in the queue waiting for a chance to run for 10 seconds, but the DO was otherwise busy serving other requests

We definitely won’t return success for a write until it has been truly persisted

The sharding bit is interesting to me. Named or unique ids?

that's good to hear! is there some sort of DO class level limit on parallel requests to different instances?

Named ids, note this process works 99.99 percent of the time, I just saw this new error for the first time last night

It's always the same 16 names `idFromName('-<yyyy-mm-dd') where domain is constant and there are only ever 16 dates for this domain

No limits across the namespace request/CPU-wise.

Can anybody confirm if

this.state.storage.list()

really works from a DO? I can put and get values, I can print out that the values exist in the same DO (checked state ID) but if I

list

I only get an empty object back.

works for me - you get a

Map

promise back. Can iterate over the entries with something like:

for (const [key, value] of await this.state.storage.list()) {...

works for me as well, I am doing something like

Object.fromEntries(await this.storage.list())

to get the object

Thanks! This works for me:

const res = Object.fromEntries(value);

JSON.stringify(await this.storage.list())

always returns

{}

I guess I'm just lacking understanding of JS

because its not object, but Map

Is there a limit on how many sub-request I can make from one DO to others?

afaik all workers have the same limit of 50 subrequests (it's pretty easy to test, it throws instead of gettting killed), although perhaps calls to durable objects might be raised in the future, per https://discord.com/channels/595317990191398933/773219443911819284/860249018096287754

Is

Durable Object -> Bundled Worker

traffic exempt from egress charges or will it incur the same charges as

Durable Object -> WWW or WebSocket

traffic?

exempt. It'll actually run on the same machine so no bandwidth is even used. 🙂

Is it a good idea to connect a client (browser) to a worker via WebSocket. Then subscribe to multiple "topics" (DO) by initiating multiple WebSocket connections to topic DOs and multiplex the messages back to the client from the worker. The idea is to avoid having the client to open multiple WS if they want to listen to multiple topics. Is this a pattern you'd say DO is good for or would you do it another way? Any limitations? E.g. duration of WS connection, extreme cost? Or can this be considered a good pattern?

What if named DO is in another colo?

Alright, thanks! So, if I do

return fetch("https://www.example.com/")

in the Durable Object and

return stub.fetch(request.url)

in the Bundled Worker, that would only get me charged for small amount of data used by headers in the

GET

request made by the Durable Object?