Thanks, I have reported the issue regarding the missing __STATIC_CONTENT_MANIFEST env here: https://github.com/cloudflare/wrangler/issues/1938 /cc @User

Thanks for diving into this!

So … did the team chat reveal anything?

People are just waking up now. And I need to go to bed now. Hopefully have something tomorrow.

Okay, thanks. Good night!

@User yep, there's a hard limit at 10,000. we're looking into increasing the limit for long-running WebSocket connections.

and this limit is for the DO across all of the connected workers?

i.e. it's cumulative: 100 from 100 connections = max

In my case, no timeout is long-lived, 30s max. So if you were rolling-over the IDs, that would be fine (but probably not spec-compliant). Without rollover, I'd need a few million at least (e.g. 100/s over 10 hours, and after that I'd prefer the DO to be restarted).

I haven't tested, but I guess the limit applies to

setInterval

just the same?

Also, is there a recommended work-around for the

Cannot clear a timeout created in a different request context

error? All of my timeouts need to be clearable.

My current workaround is this https://gist.github.com/codefrau/cd7d25ee88f034c71bba9cf6ba51f9b7

Is there a way to perform a full/partial backup/restore of what is in DO?

Why do the examples trigger lazy init on first request instead of doing async init in the constructor?

Great question. There are 2 reasons, firstly that a constructor has to be synchronous, and secondly that it does not matter in practice, because the fetch method is always called immediately after invoking the constructor and doing it in the fetch method means that it much easier to retry in case of a failure.

Of course it is always possible to do that yourself now, we currently do not have this type of functionality yet.

My thought is that the constructor is only called once. So if you start the operation in the constructor and await that promise in the fetch, the code is a bit simpler. 🙂

That is absolutely possible and was my reaction too. But that way you have no recourse if the initialisation fails.

Unless you start it in the constructor and restart it in the fetch method on a fail. But now your code is more complex again than always starting it in fetch.

Is it planned? And/or anything similar for KV?

We don't really talk much about the roadmap publicly because everything changes all the time right? But from an KV pov you should totally bug @User for a sneak peak about something he is working on 🙂

Ooh, that's exciting! Yeah, would love to see what you're working on @User 🙂

bump

Also, is DO eviction documented somewhere? Can I perform a last action (e.g. store) before being evicted (similar to beforeUnload/sendBeacon)? In case of code upgrade, can I be sure that web socket connections to the old instance are closed before the first request is handled by the new instance?

I am seeing an issue with

storage.list

and

storage.get

(multiple). I always get back an empty map when I call

storage.list

(with options or without) or when I call

storage.get

with an array of keys. For context, I am able to get and store items - with

storage.put

and single item

storage.get

. So I know the items are stored and that it is working. It is just retrieving multiple items that seems to be an issue. Is anyone else seeing that?

For example, here is a call that is using an array of keys:

Calling get with any one of those keys returns the object, but calling it with the array of keys returns an empty map.

try

JSON.stringify([…items])

that worked, thanks @User

js
let stuff = await namespace.list()
console.log(stuff.keys)
return await stuff.keys

You need to add

.keys

to the object that's returned from the

.list()

🙂