You need to update that to your domain.
You need to update that to your domain.
Gis it possible to update the template to use the worker domain or is that just something that always has to be done manually on the users end
LYou need to remove this line: https://github.com/janwilmake/dorm/blob/a818944b8a55690bed5d209011dae616a832b1e2/wrangler.jsonc#L7
Assuming that's what you try to deploy.
Assuming that's what you try to deploy.
Gthat would make the deploy button work without user intervention?
Edit: Thank you, as always very helpful
Edit: Thank you, as always very helpful
EHey there. What is the cost of messages in internal websocket connection between DOs? Is it included in incoming messages?
In my usecase, i want to use DO to DO internal websocket connection. I will send one client message to between (3+) DOs. In this case, will 1 message be counted as 3+ messages?
In my usecase, i want to use DO to DO internal websocket connection. I will send one client message to between (3+) DOs. In this case, will 1 message be counted as 3+ messages?
LFor compute requests billing-only, a 20:1 ratio is applied to incoming WebSocket messages to factor in smaller messages for real-time communication. For example, 100 WebSocket incoming messages would be charged as 5 requests for billing purposes.From https://developers.cloudflare.com/durable-objects/platform/pricing/
VIs there a way to "export" data from all DOs? Say I were to build my app using DOs, but then for some reason I need to move to some other infra, can I export the SQL data stored in every DO for migration purposes?
BNot natively, you'll have to implement that logic yourself
Fby heartbeat you mean whenever a significant action is done it calls back to the parent?
GI think they shared a script here that does what the d1 export does
JI am getting
for a specific DO ID, other IDs in the same namespace works fine. can anyone help?
for a specific DO ID, other IDs in the same namespace works fine. can anyone help?
LMy first suspicion would be that there is something in the data for the instance that is causing it. I suggest wrapping your fetch, onMessage, onRequest, etc methods with a try/catch and logging the details.
Jyeah, ive done that but i keep getting
Error: internal error
KHow do I go about debugging
Internal error in Durable Object storage caused object to be reset.
GFix Needed for Bug in CF Email Notification System general-help[Cloudflare]: [ACTION REQUIRED] Daily usage limit exceeded for Cloudflare Durable Objects
DMore than a direct use case, I was hopeful read replication would enable dynamic relocation of DOs. If a worker accesses the DO from another data center it gets read replicated right there. After the DO gets evicted, next time it's accessed, if there was already a read replica in the new data center, that replica gets promoted to write leader.
Also, it'd be nice to have locally replicated DO sqlite files for debugging. Maybe with something like
Also, it'd be nice to have locally replicated DO sqlite files for debugging. Maybe with something like
wrangler do --namespace <ns> read <id> <db.sqlite>
LAlso, it'd be nice to have locally replicated DO sqlite files for debugging. Maybe with something like wrangler do --namespace <ns> read <id> <db.sqlite>You mean, doing an export/dump/copy right once? You don't expect things to be replicated locally in real time when changes happen remotely.
After the DO gets evicted, next time it's accessed, if there was already a read replica in the new data center, that replica gets promoted to write leader.This is something that we are thinking about but not as part of read replication. Moving the primary should take into account more than just a single request, so it wouldn't work like that, but yeah the team at some points wants to be able to move primary DOs.
DYou mean, doing an export/dump/copy right once? You don't expect things to be replicated locally in real time when changes happen remotely.Right, I don't really care about real-time. I was thinking about explicitly doing a one way sync with a command, maybe
pull
Jlong time wish: export/backup/archive DO with read-only access to another DO's storage but without competing with the main DOs incoming request queue - a minimal replication delay would be fine
Vwhy is the 10gb limit a hard limit? it's not like the data has to travel to other locations, given that a DO only ever exists in the datacenter it was created.
LFew reasons, cold starts would be very slow and it would be hard to get the fast SQLite performance from local queries if you had to load pages from remote most of the time (even with caching). Also, the fact that the DOs do not move (yet), is just because it's not implemented, yet.
Jis this still in the works? it’s been almost five years since the announcement that cloudflare “can transparently migrate objects between locations.”
LThere is transparent migration already, but only when the original location is down, and not due to request traffic.
GI think they said this will fix it durable-objects
Jwill DOs re-initialize whenever theres a new deployment that changes code? meaning, will the
constructor
1No but any open/hibernated Websockets will be terminated
Ji see, but how can a js class have it's underlying code updated to even receive the new migrations in the file w/o actually re-initializing the class?
1It will get called the next time the DO is accessed, but not immediately upon deployment. Sorry if thats what you meant
Ji see. then do you know why for migration libs like this: https://github.com/lambrospetrou/durable-utils?tab=readme-ov-file#sqlite-schema-migrations
require
require
await this._migrations.runAll(); await this._migrations.runAll();GitHub
Utilities for Cloudflare Durable Objects and Workers - lambrospetrou/durable-utils
Llambrospetrou favors doing it "lazily" in case you have functionality in your DO that doesn't need stored data. If that's not the case for you, doing it in the constructor is fine. That's what I do.
Jthanks!
what does this mean necessarily?
that doesn't need stored data
what does this mean necessarily?
LLet's say you have a method that accepts two numbers and returns the sum. No stored data is involved.
Jah yea i get that, but if you have migrations in your DO, you always have stored data im assuming?
LYes, but part of your DO's functionality might not use stored data. A commonly accepted software engineering principle is to not do work until it's needed.
Ji see i see. thank you!
LExactly what @Larry said. I need to update the README of my library to explain this since many folks ask about it at this point. It seemed a bit obvious to me, but I was wrong assuming that.
JThe internals of the DO and when constructor gets called and stuff isnt so obvious
JThanks though, amazing library
DI'm still hoping one day we'll have DOs in all colos, even if storageless - the use case is for websocket handling and chat rooms where persistence is external anyways
ZIsn't storageless DO just a worker? 
Dyou can't use hibernation, connect multiple websockets to the same worker, so not quite
ZAh I see
Dbut I see where you're coming from, for a simple proxy, or maybe a filtering/logging service, yeah regular workers are just fine (even better for some things since no wall time charges)
LThe big benefit of DOs over workers even without storage is coordination due to the global uniqueness of the DO ID.
TWe just had a customer having an outage on an important realtime-flow because a DO was hanging for >1h - no requests timed out, they were hanging in pending state.
I'm a bit out of ideas here - since there are no errors, or no indicators on why this suddenly happened.
A re-deploy fixed this, and all connections were reset.
I'm a bit out of ideas here - since there are no errors, or no indicators on why this suddenly happened.
A re-deploy fixed this, and all connections were reset.
T(This wall time is from an alarm in a different DO that uses RPC to connect here)
TIn the morning we had requests erroring with an overload error - self-recovered just fine after the load was gone. But this time, we're a bit clueless - especially since there was no self recovery :/
TThe DB in the DO is still relatively small for DB standards, with just 50k records. Nothing that should hit the limit.
T@Sunil Pai - this was a partyserver DO with hibernation, not sure if you have seen this one before