Btw, they still didn't merge this and return values for transactions remain broken with the DO drive
Btw, they still didn't merge this and return values for transactions remain broken with the DO driver
BJust pinged again 
BTests are running and merging for that PR right now 
JI found good results using drizzle kit to define schema and migrations, but for runtime, I have a simple custom handler for casting types on return from the DO using the existing schema definitions in TS.
The only aspect one needs to be careful with raw SQL and this approach is consistent type casting on writes for fields like dates as numbers or string however you choose to store them.
The only aspect one needs to be careful with raw SQL and this approach is consistent type casting on writes for fields like dates as numbers or string however you choose to store them.
JThe side perk to custom SQL is it's much much easier for an LLM to debug/refine code based on the SQL. It's a level of indirection with ORMs sometimes.
LI find myself more and more optimizing my software design decisions based upon the cognizability of it to an LLM. A funny thing about my own code and LLM use is that if I have poorly named identifiers it can throw it into a doom loop. I called something "serialize" and there was JSON in the area and it constantly thought the output was a string, but it was really pre-processing before turning it into a string. Once I renamed it, the LLM had no trouble.
AIs the lifetime of a DO predicable? How long until it kills itself?
AI have a semi-short lived use case, for stateful requests, and don't feel like they need to store to a persistant store, but I'm worried they'll be prematurely killed.
AIs it after 5s in-memory is wiped, or longer?
ACan't find resources on this.
LIt's a bit complicated, but look here: https://developers.cloudflare.com/durable-objects/concepts/durable-object-lifecycle/
Cloudflare Docs
This section describes the lifecycle of a Durable Object.
LFocus on the diagram. It has the timing of eviction and hibernation.
ASo, according to this, if I queued no-operation
setTimeoutYes. That's one way people keep DOs alive. I think some people also use alarms. Not sure which is best.
TIs there a way to execute a worker from a DO where the walltime of this worker is not added to the walltime of the DO?
It might be a bit cheeky, but what I am trying to do:
However, and documentation suggests the same: Cloudflare is being nice (which I appreciate btw) and doesn't charge for the second worker invocation. But also adds the walltime of the second worker to the DO walltime. And I can't find a way for it to stop doing that
I tried several things:
It might be a bit cheeky, but what I am trying to do:
- Have a DO take care of administration for my users.
- Once in a while (via alarms), the DO asks a worker to check in with an external API for an update.
- This external API can be extremely slow. Think 10+ seconds to come up with an answer. As such, the worker returns a response near-instantly, while via the external API fetch is finished, and a D1 table is updated.
- This way the DO isn't blocked on the fetch for very long.
However, and documentation suggests the same: Cloudflare is being nice (which I appreciate btw) and doesn't charge for the second worker invocation. But also adds the walltime of the second worker to the DO walltime. And I can't find a way for it to stop doing that
I tried several things:
- Use service-bindings (works, but walltime is added together)
- Use service-bindings and set smart placement on the worker (works, but DO now shows both requests in the GB-s graph, suggesting they are both billed under DO pricing)
- Use direct HTTP (doesn't work, as you can't call a worker on your own account from another worker without a service-binding, it seems)
HDO invokes Worker via Service Binding, Service Binding returns after initiating work with , allowing Durable Object to be evicted. Worker continues processing, and then once complete, uses the calling DOs ID to create a stub to it, and returns the response.
TThat is what I tried. But the walltime of the second worker is added to the DO, the dashboards tell me 
TBasically I am trying to bypass https://developers.cloudflare.com/workers/platform/pricing/#service-bindings 
But my experiements show for a DO it should read "walltime", not "CPU time"
But my experiements show for a DO it should read "walltime", not "CPU time" HTo confirm, the Worker immediately returns to the DO, right?
TYes
HIt doesn't do any work first?
TThe DO object itself is also evicted in a few ms
TSo from whatI can tell, everything is working exactly how you (and I) expect ... except for where the bill lands
HJust to confirm, does your bill reflect that, or is this only in the dashboard?
TDashboard. The "Request Wall Time" of the DO, to be more exact.
Tor "Billable Duration" for that matter
TNo, I am wrong. The "Requests" and "Request Wall Time" combine both the DO and Worker. But "Billable Duration" appears to only account for DO walltime.
But the second workers dashboard only shows zeros, not even CPU time.
Now I am just confused
But the second workers dashboard only shows zeros, not even CPU time.
Now I am just confused
GHad that with a value called redis , was painful to watch
BI've tried ORM, query builder, and raw SQL in various backend projects. They all have their issues, but nowadays I'm leaning more towards raw SQL end of the spectrum.
GYea I started with an orm because a starter I was using had it pre configured but it was way more trouble then it was worth, especially because AI is very good at writing sql when you give it a spec
FHi I'm looking to use Cloudflare DO x Websockets, can anyone share their experience on reliability and scalability of it?
LThe key is to assume the connection will break often and design for reconnection and resumability. If the server never needs to initiate communication, I use a lazy [re-]connection strategy where the next time the client needs to send something, it first checks if the connection is up and if not re-connects. For situations like chat where you need the server to reach out to the client, you will have to use the hooks for sensing when the connection is broken and reconect. There is a package that Cloudflare Agents use for this purpose. I have forked that for my own purposes but you could just use that.
SIs there a way to register an unhandledrejection event handler in Durable Objects?
LWhat do you mean by "rejection"?
SCloudflare Docs
Standardized APIs for use by Workers running on Cloudflare's global network.
LWhen I return a DO stub over Workers RPC, in vitest environment, the connection breaks unless I use setTimeout. Is this a known limitation of vitest, also what happens in prod, or am I just doing something wrong? I can share code if you like?
1Are you returning an ?
1Also for testing, is the DO class being returned in the same Worker? If not, you might need to run both Workers concurrently but I don't have much experience there
Jlooks like JSONB support is now available in sqlite DOs, thanks so much to whoever made this change!
1There needs to be a better way to track logs on a DO, especially when working with WebSockets. I have a DO that manages inbound (hibernated) sockets as well as multiple outgoing socket connections, as well as alarms and HTTP requests. Every WS message I receive I log, but those logs can be split between the different events that the DO manages. I can see the full list of logs for the current IOContext() of the outgoing sockets within the event invocation of the alarms, which feels very unintuitive. Should I be pushing the logs to observability or elsewhere instead of relying on the built-in logic?
LI had a chance over the last week to do a deep dive on Cap'n Web. Here is my multi-page writeup as a comparison to my own Lumenize RPC. Please let me know what you think. I'm particularly interested in hearing if I've misconfigured anything on the Cap'n Web side which would explain some of the troubles I had: https://lumenize.com/docs/rpc/capn-web-comparison
Comparing Lumenize RPC to Cloudflare Cap'n Web
LIs there a way for a DO instance to know what binding name was used to connect to it without explicitly passing that in? I know it's tricky with service bindings to it's not consistent so I'm guessing the answer is "no" but thought I'd ask.
HNot yet. The tricky part is that names aren’t bounded by size, so theoretically you could have a 50 MB name, which is not great to be shipping around the world. Though iirc the team is looking into supporting it somehow
AI'm seeing some strange behavior after destroying a durable object.
I have this destory method():
When it executes, I see normal logs:
Then strangely, a few seconds later I see this:
After it's destroyed, something else wakes up the DO only to warn me that an alarm was replaced. Why is this happening?
I have this destory method():
When it executes, I see normal logs:
Then strangely, a few seconds later I see this:
After it's destroyed, something else wakes up the DO only to warn me that an alarm was replaced. Why is this happening?
AYes, the destroy() is called from within an alarm.. it's a sort of TTL where I tell the DO to destroy itself sometime in teh future. I do catch the exception thrown by abort() tho...
Aand the destory is working, i can see everything wiped in the sqlite file
Athat I don't know, just following code i saw in some examples
LThanks, while we're on the subject, is always valid even when you got to the DO via , meaning I can use it as a "return address" for in-Cloudflare communication even if my client-side application always uses the name?
HIt should be, since is just a convenience utility mapping to I think
LYes, the ID is always populated and correct. And you can route to a DO by the ID even if other callers route by name.