whats the method called if I already have the ID

ie, if I do ``id.toString()`` cant I use that in future requests?

@User @User Deleting all of the durable object's storage causes the object itself to disappear from existence once it shuts down.

oh cool

I mean, that makes sense

the only real persistence it has is the durable storage

so if theres no durable storage it might as well not exist after its shutdown

right

what were the other methods of getting an ID besides ``idFromName``?

the only one the docs use is ``idFromName`` as far as I can tell

idFromName()

,

newUniqueId()

, and

idFromString()

-- the last one just parses back the hex that

id.toString()

produces

ah right

cool

(note that

idFromString()

will only work with IDs that were actually created by stringifying a valid ID for the same namespace -- it doesn't accept just any hex)

gotcha

I don't think we'd auto-store properties of the object, because what happens when the property isn't serializeable? For example, people may store a list of open WebSockets in a property of the object, and those can't be serialized. It's cool that there's a project that implements this as a library but I don't think we'd want to have it built-in because there's too many questions about exactly how it should work.

Nice! Thanks.

Makes sense... For this king of durable you may just limit for serializable properties as limitation. My questions is more about the optimization oportunities to do that outside the JS. For example, you can shutdown the durable early because you can make sure that all properties are safe.

I don't think there's much we could do to make it more efficient. Safety is an interesting issue, though. If you are just setting a property on the object and then expecting itty-durable to write it later, you might get silent data loss if, say, the power goes out before the write actually happens. It's important to actually wait for the write to report success before you report success back to the user. But we actually have some changes coming soon which will make it much easier for itty-durable to get this right.

Nice, looking forward with that. Im not actually using itty-durable because i need more control (including save the properties in a different pattern), but i can see a value of something "simple" as direct class call; Anyway, two small questions: - What is the expected latency of a DO call when the worker is on the same datacenter? (i cant test that because theres no DO in my region) - Will DO calls always be part of the 50 subrequest limits of a worker? We dont have this limit to call a KV, only the six connections open simultaneously; Thats make more sense to me.

> - What is the expected latency of a DO call when the worker is on the same datacenter? (i cant test that because theres no DO in my region) A couple milliseconds, I would expect. > - Will DO calls always be part of the 50 subrequest limits of a worker? We dont have this limit to call a KV, only the six connections open simultaneously; Thats make more sense to me. Indeed, we should probably change this.

I'm trying to send a fetch to an external site that is using self-signed certificates. I can curl to the site fine using insecure but from inside a DO it just fails with a 522. I even tried just fetching and it seems to work fine. Is there a limitation to fetching to webservers with self-signed certificates?

Hi guys @User suggested I post in here. We are currently evaluating moving our backend over from Heroku to Cloudflare Workers for our game (https://battletabs.com). The tech looks good but we are trying to get a sense of the pricing of things. 1. I read that you plan on charging only for the time the message is being processed in the Durable Object, is this still the plan? So you wouldn't be charged for the time that a connection remains open but no messages are sent? 2. The GB/s pricing model you use confuses me a little bit. If I give you an example can you estimate how much it would cost? Say I had one user connect and stay connected for 1 day. Say they sent 1000 messages and received 10,000 messages in the day and each message took 10ms to process, how much would this cost?

I keep hitting " too many concurrent storage operations from this account"

But not sure why

Does not seem to be an operation limit?

> So you wouldn't be charged for the time that a connection remains open but no messages are sent?

the blog post said that you would be charged a different rate, but not no rate.

websocket connections aren't free to persist, so there would still be a fee for active connections, but it wouldn't be billed as 'wall time' afaik