That's fine for right now! I'm excited about the tech and the opportunities it brings, so I'm okay with cutting myself on some rough edges!

can durable object classes extend other classes?

Yep!

I use that to abstract away virtually all the boilerplate stuff (storage persist, initialize, fetch, etc)

exactly my plans, hahah

Shared the magic yet?

Not yet! Got sidetracked by the great dialogue yesterday and surgery (my gf) today... I’ll be back on it while she rests!

Hope all is well!

I've spent ages trying to figure out why I'm not able to use the

state.storage.delete()

method to immediately delete keys from a Durable Object. Here's the strange thing. I can see that the method is deleting keys, as it returns

true

for each deleted key (and

false

if the key didn't exist). However, when I retrieve the keys, they are still there with their values!!! Now the bizarre thing. As soon as I republish (e.g.

wrangler publish

) the keys are deleted, without even making a call to the Worker! I was hoping that someone could provide some insight here. Refer to my attached Worker and durable object script.

If I am reading your code right, it looks like you're deleting the keys from persistent storage but not your in-memory instance, is that right? You may need to also do something like

delete this[key]

(and probably validate that key before) along with your

this.state.storage.delete(key)

Oh, that makes total sense now. Thank you so much!

@mehdiiii! Glad you joined the channel! 🥳

He’s the actual genius behind why itty is so tiny (and why I’m still obsessed w proxies) - I’m just the imposter that published 😜

not sure about "genius" but ty 😁 I've been playing with durable objects the last couple of days! really cool tech, lovely work by the team

Now scroll back up the thread and see if you can help solve the async proxy set trap dilemma

are durable objects encrypted? or would we have to do that ourselves?

I dont know if its DO related, but first requests from given locations are errored with

Network connection lost.

🤔 It seems to be happening only on routes that interacts with DO somehow

I ran similar errors the other night but didn't trace it down... which is basically to say, me too!

is there any good way to try to get a stub but only if it already exists?

I’ve been storing a log of them in KV, then checking that for existence first

I'm finding some weirdness around 'this' with DurableObjects. I started from the CommonJS template and am seeing some build weirdness. Sorry if this is a JS n00b question but a few colleagues have looked at this and are also confused. Specifically in this file: https://github.com/joshtwist/SimplestWebSocketDurableObjects/blob/master/src/WebSocketDO.js The this object seems unavailable in the fetch function (blows up on this.sessions.push). Obviously, I don't instantiate this object, CF Workers runtime does. I tried changing the function to lambda but this generates a build failure. Any ideas what might be going on here?

you have constructor misspelled, so it’s never being called (and sessions isn’t being initialized)

ha ha

Well, this is the walk of shame

Is there a way to get the DO name from inside the DO?

Is there a DO destructor?

That gets called when the DO shutsdown?

Is the initialPromise still needed?

Or the constructor can call storage.get?