Is there a way to “re-instantiate” a specific do?
Is there a way to “re-instantiate” a specific do?
1What do you mean by that exactly? you can delete its storage which essentially resets it
Jtheres some DOs that just give "internal error; reference = moh644b953d9vckab1seqm9a" and I cant access it at all
Jlike i want to delete them and re-make it from scratch
1Is that just by running the constructor? What is the instance trying to do when it errors like that
1You can only delete them from within
VDoes anyone know the exact error message when a SQLite DO exceeds the 10gb of storage?
VI made a random generator and filled a local DO, but it appears wrangler local doesn't simulate the 10GB cap
Smy guess is RangeError 
Pcould look at databaseSize
AHello, I'm looking at using Durable Objects as a Websocket server. I'm a bit confused by the Hibernate API, and this SO post.
My confusion is that I thought the whole point of DO was to be a "stateful worker". But this comment seems to claim the opposite (might just be bogus). That said, the docs also claim that:
Am I misunderstanding the point of DOs? Or is this just an edge case with the hibernate API and I should use
Since DurableObjects are basically in-memory classes, their long-term state cannot be guaranteed - especially in cases which involve the Hibernation API. When the DurableObject hibernates, the existing websocket connections are kept alive "outside" of the class - and when one wakes up, the Workers runtime will reinstantiate the DurableObject with a new state.
My confusion is that I thought the whole point of DO was to be a "stateful worker". But this comment seems to claim the opposite (might just be bogus). That said, the docs also claim that:
// ... During periods of inactivity, the Durable Object can be evicted
// from memory, but the WebSocket connection will remain open. If at some later point the
// WebSocket receives a message, the runtime will recreate the Durable Object
// (run theconstructor) and deliver the message to the appropriate handler.
Am I misunderstanding the point of DOs? Or is this just an edge case with the hibernate API and I should use
serializeAttachment / deserializeAttachment to store persistent state?
UDurable objects are not exclusive in memory storage and can absolutely store stuff permanently (that is indeed the entire point of them wouldnt be durable otherwise).
The attachments on a websocket connection will exist as long as the client is connected regardless of the DO being evicted and then reinstated down the line. However, if the client disconnects then the attachment will go away.
You can use memory only state that doesnt get durably stored if you wanted but you can also use durable storage.
The attachments on a websocket connection will exist as long as the client is connected regardless of the DO being evicted and then reinstated down the line. However, if the client disconnects then the attachment will go away.
You can use memory only state that doesnt get durably stored if you wanted but you can also use durable storage.
AAh I see. Seems the bit I was missing is that that durable storage is separate from the memory state. RTFM I guess. Thanks for the help.
Vif a durable object is "hot" (so if i was to make a new request now the constructor would not run) and I deploy a new version in the meantime, would the constructor run again (kinda like "shutting down" the DO)?
1If its 24/7 operation then yeah VPS will probably be best at the moment, Containers are coming to CF :soontm: which might be a better solution that's on-platform
1My hope is that using DOs as a hibernatable client will be possible in the future, but nothing specific has been hinted at yet. I'm super keen for containers, I have so many interesting use cases
LHave you considered using the "backfill window" capability of ATProto combined with an alarm that is shorter than that window to accomplish the same thing. I'm not familiar with Jetstream, but maybe it supports this.
Alternatively, you could use CBOR-X over WebSockets to subscribe directly to ATProto. It seems like the only thing Jetstream provides is converting CBOR to JSON, but that's what CBOR-X does as a library instead of a service.
Alternatively, you could use CBOR-X over WebSockets to subscribe directly to ATProto. It seems like the only thing Jetstream provides is converting CBOR to JSON, but that's what CBOR-X does as a library instead of a service.
EWith durable object migrations, do I need to do migrations for each env? Or just a top level one?
Vis
this.ctx.storage.sql.exec("select * from artist where artistname = ?;", "Alice"); safe against sql-injection or do i need to worry about that?
Vnvm found the answer
A<just kidding, not a real question>
From the documentation:
It takes light around 50ms to cover the earth. Why does this check take several hundered milliseconds? So seems there are other limits than just speed of light ?
From the documentation:
It takes light around 50ms to cover the earth. Why does this check take several hundered milliseconds? So seems there are other limits than just speed of light ?
Cloudflare Docs
A Durable Object namespace is a set of Durable Objects that are backed by the same Durable Object class. There is only one Durable Object namespace per class. A Durable Object namespace can contain any number of Durable Objects.
SSpeed of light in the fiber is 0.6 of the speed in vacuum, plus cables are not in a straight line, plus reads from disk and other processing === long delay. Also, round-trips, probably more than a few
Pplus checking lava lamps
MCan't find this mentioned elsewhere - is there a timeline for when
wrangler dev --remote will support SQLite DOs?
AReads from disk + other processing makes total sense. I am just saying, lets not blame it all on the speed of light.
SWell, round trip for tcpip three way handshake will add a lot to that, plus any other round trips. The check is fast, I am sure
P“has not been created anywhere else” “round-the-world”
defo not a distance reason
defo not a distance reason
BSpeed of light is most definitely the primary factor. Here's a table of the network latency between the most popular DO locations. If the instantiating colo needs to confirm with all other colos, you're waiting for the slowest responder to finish.
https://where.durableobjects.live/ provides a map of all the DO colos. It also shows latency metrics between all edge POPs and DO colos.
https://where.durableobjects.live/ provides a map of all the DO colos. It also shows latency metrics between all edge POPs and DO colos.
BYou got this clarified for us last time 
B
Sim surprised theres still 0 DO POPs in south america 
Si dont get your argument here
HFor DOs to be deployed in a colo, there needs to be a certain number of datacenters within that colo, for redundancy. If a colo doesn't have enough DCs, it can't run DOs(or at least not without a modicum of disaster recovery)
Sinteresting considering oceania barely has any while south africa has a lot? unless i misunderstood this https://where.durableobjects.live/colo
Where Durable Objects Live
Tracking where Durable Objects are created, wherever you are in the world.
HNot sure I understand what you mean? South Africa(the country) has 3 colos, while the general Oceania area has 11 colos, at least from a visual count
Ssorry meant south america
isnt every circle a datacenter?
“For DOs to be deployed in a colo, there needs to be a certain number of datacenters within that colo”
all i see is that australia has like 7 with 3 of them supporting DOs
while brazil has like 15+ and no DO ones
isnt every circle a datacenter?
“For DOs to be deployed in a colo, there needs to be a certain number of datacenters within that colo”
all i see is that australia has like 7 with 3 of them supporting DOs
while brazil has like 15+ and no DO ones
Sim probably just confused here
Sor is a circle a colo and we dont know about the dcs?
HBasically, a Colo is 1-or-more datacenters within the area of a city. So for example, GRU might be a single datacenter, or it might be 20.
Where Durable Objects Live
Tracking where Durable Objects are created, wherever you are in the world.
HAnd if I remember correctly, the resiliency requirement for DOs is n-datacenters within that colo
Sahh i see i see makes sense thanks
HI always get them mixed up tbh
THi all durableObject experts,
i have a download process that downloads multiple parts from R2, i was wondering if its best practice to use durableObject for download session, every time user download a multipart file, i want to keep track on each part he downloads and if he finish downloading all the parts i want to enqueue an event to a queue.
my other option is to use one durable object for R2 file, and use JWT for session token, so multiple downloads per file are going to be tracking JWT token, part number.
what do you think will be best and why?
i have a download process that downloads multiple parts from R2, i was wondering if its best practice to use durableObject for download session, every time user download a multipart file, i want to keep track on each part he downloads and if he finish downloading all the parts i want to enqueue an event to a queue.
my other option is to use one durable object for R2 file, and use JWT for session token, so multiple downloads per file are going to be tracking JWT token, part number.
what do you think will be best and why?
AWhy is there a cpu_ms limit? If there are several requests in a row, does that increase the cpu limit? Is it possible to deactivate it?
WQuestion about deleting a DO instance which has me confused... even after calling
deleteAlarm() and deleteAll() the Cloudflare API says it still exists via the endpoint /workers/durable_objects/namespaces/<id>/objects... Any insights would be appreciated.PI’m still facing this issue. My current workaround is storing a reference for the DO so i can run another cleanup later (which eventually helps clean everything up)
I’ve noticed some of them eventually persist after first delete (no additional cleanup) if i don’t touch the DO after a few hrs
I’ve noticed some of them eventually persist after first delete (no additional cleanup) if i don’t touch the DO after a few hrs
HI know that on the backend, once a DO is created, it isn't ever garbage collected. As in, if I create a stub to the same DO ID, it will spawn in the same place, even days/weeks later, even if it doesn't have any storage attached. I'm not sure if that applies to the API too