Are there docs anywhere that say you don't need to disconnect a db driver from Hyperdrive?
Are there docs anywhere that say you don't need to disconnect a db driver from Hyperdrive?
HMaybe try in #hyperdrive
RI am getting a 500 when trying to use the data studio, the same sql works fine when I run it inside the DO "SELECT * FROM sqlite_master"
LRe set it in the constructor. That will get called next time it's accessed after the deploy.
JI want to publish an npm package for use in cloudflare projects that includes a pre-written durable object. End users would install the package, add a couple lines to their (unless there is a magic way to not do this step) — and viola they have this particular durable object working.
I have 2 questions:
I have 2 questions:
- This import assumes can be resolved, but of course that is only importable with a build tool like vite. Should I bundle cloudflare:workers as an internal dependency? What would the CF team recommend?
- How does the property of wrangler's config work? Can it resolve a class that is in a dependency?
LTrue. I hadn't thought of that. What if you set the new alarm at the beginning of your handler for the current alarm instead of at the end?
K comes from file that gets generated from config using . Durable object is just a typescript class that you import to your project and add to your wrangler config.
Jthats where typescript gets it, but it has a concrete implementation too doesnt it?
KI don't know the details about the runtime but since class_name must be the name of the class I guess thats how they know it.
HYou should mark it as an external dependency. Treat it like imports to -prefixed packages
JThanks, will do. As for the property in the config, how does that resolve to the actual class? Seems a bit magical — would love to understand that part more.
HIt's the name of the export in the Worker's file. So for example, if your package exports a DO named , it would look something like this:
Jok excellent. thank you for that clarification
JLast question (for now 
) is there any way to "extend" a from some base — sort of like a ?
) is there any way to "extend" a from some base — sort of like a ?HNo, there is not
1I just got the following warning in a Worker that creates a bunch of DO stubs in quick succession (and doesn't explicitly dispose of them). My understanding from reading the docs was that the disposal is technically optional as the runtime will do its best to dispose of them when necessary. Is there a certain limit I'm hitting where I need to start explicitly disposing?
LIf you use , the local resource is disposed but not the remote one. This is worrisome because it keeps the remote in wall clock billing mode. I don't think it matters, but I'm curious, are you doing DO to DO or are you using RpcTarget on the caller side?
1It's RpcTarget but I definitely don't use . Lemme add that in and see how I go
1In this specific case it's only a single RPC call too so it doesn't even need to be a full stub necessarily. My VsCode autocomplete just does its own thing 
LI don't do this and it still seems to work. Where are you saying to specify this and how? I've never done it for a node:* dependency either, but my plain node packages go back to before they had node:*, I think.
HI guess maybe it automatically guesses if deps are external or not? I meant more, if it throws errors because it can't find , then you should mark it as external. If it already works, no need to change it
B(Also this only matters if your package project is built with a bundler)
1This fixed it thank you, now I definitely need to go through and add to like 20 different Workers
LAhh, that makes sense. I use tsc now to prep for publishing to npmjs.com
NWow Larry you put in a lot of work. As for the rquestion. The DO is like the controller and optimistic state which is called from a normal worker. So the functions have to return so that the worker can return back to the user.
One example is if old data needs to be purged to make room for new data. I simply save which data that is, set the alarm and then return back to the user. Some time later the alarm will fire and delete the data. At the same time the DO is meant to only be optimistic state so after inactivity or no longer relevant data it should just self destruct.
One example is if old data needs to be purged to make room for new data. I simply save which data that is, set the alarm and then return back to the user. Some time later the alarm will fire and delete the data. At the same time the DO is meant to only be optimistic state so after inactivity or no longer relevant data it should just self destruct.
NI'll give these a go
LWow Larry you put in a lot of workTrue, but a lot of what I'm doing right now is cleaning up and open-sourcing stuff we already use. It still requires cleanup, more tests, and documentation. As a side effect, we've fixed some bugs, improved the internal DX, and made it easier for our devs to work.
JAbout the 6 simultaneous outgoing connections limit, are there any plans to make it easier to work around it? I remember reading somewhere that 6 was chosen as the limit because its the default for some browsers, but acting as a server there are some real-world scenarios where we would benefit from having a higher limit.
Right now the options seem to be calling a worker through HTTP (so they don't share the resources and limits) or spawning a new DO instance, which is what I'm doing currently. Both sound very inefficient and can add unnecessary complexity for such a simple thing.
Right now the options seem to be calling a worker through HTTP (so they don't share the resources and limits) or spawning a new DO instance, which is what I'm doing currently. Both sound very inefficient and can add unnecessary complexity for such a simple thing.
JThis is a very noticeable bottleneck when dealing with Queues, for example
NWe have automatic geo-routing at Rivet too. Additionally – a lot of folks run RivetKit on Durable Objects since Cloudflare provides unique features or run a hybrid of Cloudflare for managed & Rivet on-prem. Happy to chat in our Discord if you have any further questions to keep this channel on topic!
Khey folks, was poking around @Brayden 's actors library and thought it would be worth asking here.
suppose i have a UserDO where i want to store event logs per user. the id would be the user ID, so there would be a SQLite table representing every user event. i liked what the actors framework was doing, where you could have a dedicated "tracker" instance that would update on create / delete of every DO so that you can scan the other DOs.
i was also thinking that it could be helpful to:
suppose i have a UserDO where i want to store event logs per user. the id would be the user ID, so there would be a SQLite table representing every user event. i liked what the actors framework was doing, where you could have a dedicated "tracker" instance that would update on create / delete of every DO so that you can scan the other DOs.
i was also thinking that it could be helpful to:
- support partitioning so that the users are collocated on the same tracker (e.g. if it's a b2b saas application, maybe you want the users to be partitioned by org so each tracker's ID would be org+tracker suffix; or maybe you want to collocate the tracker DO by geo)
- add columns to the tracker's users (e.g. if a user has properties like age, createdAt, etc.), so that you could query them later
- support repartitioning so that if the durable object for one tracker runs out of memory, it could fan out with a master-slave architecture.
JJust found the post where I read this: https://community.cloudflare.com/t/2019-9-19-workers-runtime-release-notes-concurrent-subrequest-limit/115546
NAm getting
when running
the alarm seems to still work actually. Not sure what the setName function is for since it's not in any of the examples. (https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts)
when running
the alarm seems to still work actually. Not sure what the setName function is for since it's not in any of the examples. (https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts)
GitHub
An easier way to build with Cloudflare Durable Objects - cloudflare/actors
1Assuming that the DO is not processing any other requests in between, will a 1second alarm interval always execute as close to 1000 milliseconds as possible (also assuming everything else in the universe works as expected)? Has anyone benchmarked performance here? I have a counting timer that I want to synchronize between clients, my current process tells all clients when to start counting (providing a datetime ground truth), then each client handles their own timeouts to manage counting up. I would prefer to sync over WS but only if I can keep the interval as close to 1000ms as possible. The timer is used for tracking state in sports matches, so if each tick is more than 10ms out of sync then it'll add up very quickly
PI would prefer to sync over WS
No idea about the timer precision (I'd imagine there is some variability there), but websocket jitter would be more then 10ms, right?
1I'll be lucky to have more than 5 clients connected at a time, in my experience sending simple WS messages can be completed in single millisecond timeframes. I can also do an interval of under 1second (say 975ms) if I know I'm going to have a semi predictable delay with each tick (I do this currently with awful accuracy lmao)
LI don't know the numbers off my head, but I can easily see it breaching the 1s throughout the day. Also, keep in mind that a single retry starts with a 2s exponential backoff, so you already are way ahead of your limit there. That is if there is a possibility your handler will fail.
LIs this a troublesome use case for Alarms? Just by listening to people talk about on here, including you, I'm getting the feeling that anything less than a minute, might be troublesome?
LI know many users do Alarms with such low frequencies, I do a few seconds myself too, but requiring every second accuracy seems a very easy thing to go wrong, in my opinion.
At that rate the DO is always active anyway, so probably using a larger alarm and then setTimeout could give you more accuracy. The alarm would only be for making sure you get external retries in case of a crash.
At least that's my current approach for few things. But, as always it depends on the use-case. I don't know if there is a hard guarantee on alarm invocation time at the tens of milliseconds level.
At that rate the DO is always active anyway, so probably using a larger alarm and then setTimeout could give you more accuracy. The alarm would only be for making sure you get external retries in case of a crash.
At least that's my current approach for few things. But, as always it depends on the use-case. I don't know if there is a hard guarantee on alarm invocation time at the tens of milliseconds level.
Nany idea about this?
Gin general you need to be careful with alarms. Its very easy to accidentally have them loop with short timers or by having a memory error in something tied to an alarm. I generally do every 10 seconds if being in memory already would benefit the task or 30+ seconds if it doesn't or if I don't want to have a huge rush of requests
GI also use them all the time since its an extremly usefull way to handle long running tasks entirely in code, but its a double edged sword and can add complexity if not properly setup
GI haven't tried it yet, but if anyone is trying to do a lot with durable objects then its probably worth looking into using lumenize to have workers handle the actual fetch etc to be more efficient and save on billing https://lumenize.com/docs/proxy-fetch/
Offload Requests to a Worker and/or a Durable Object and have it execute a handler when the fetch is done
P(I think your link is malformed)
Gyou don't visit the .com root every day? Thanks
1Appreciate the discussion on this. My use case only needs to stay within a few seconds for around 30 minutes at a time. I'm also not fussed about forcing the DO active as it will only be for a few hours a week per DO (maybe 20 DO instances total) so not any decent scale. Sounds like I need to not stress so much about syncing every second, will have a bit of a think about it
1does the durable object jurisdiction param only matter upon creation
1i.e. create the DO with the eu jurisdiction param (once), then omit the param forever afterwards