You should mark it as an external dependency. Treat it like imports to `node:`-prefixed packages
You should mark it as an external dependency. Treat it like imports to
node:
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
mainok 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 tsconfig.jsonNo, 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
using
1It's RpcTarget but I definitely don't use
usingIn 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
using
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
1knowing this will either be a few or many lines of change
HI would just keep it, there isn't really a reason not to send it
1im just wondering if its redundant
HIt shouldn't be? Though actually, it might error if you don't provide it?
1
1so it isnt redundant
HYeah
1thanks
BIf you generate and query by name, you have to supply the jurisdiction. If you use durable object IDs, the jurisdiction is embedded in the ID so you don't have to limit the namespace. This has been my experience
Chey folks, supposing I wanted to bind a sandbox to an internal service (separate DO), is that possible? I was digging around the docs and didn't find anything too promising, but wanted to double check here.
basically I want to be able to do something like:
worker → create sandbox, execute commands in a loop → sandbox-backend (handles things like auth)
feel free to also redirect me if there's a better channel
basically I want to be able to do something like:
worker → create sandbox, execute commands in a loop → sandbox-backend (handles things like auth)
feel free to also redirect me if there's a better channel
H?crossposting
SPlease do not post your question in multiple channels/post it multiple times per the rules at #
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.