I don't think this exists right now, although it's been discussed a couple of times.
I don't think this exists right now, although it's been discussed a couple of times.
MWith many Worker and Durable Object classes, it’s challenging to get a high-level picture of how everything fits together.
LThe UI gets a lot of love lately, so I am sure (or I hope) this will get some attention at some point as well.
NIs there any way to access the request ID of the worker that called the durable object from inside the handler somehow? Without having to manually plumb it in.
LAre you using RPC for the call?
LWhere is the request ID coming from in the Worker? Headers on an HTTP Request?
II am trying to create a worker with a durable object attached via Terraform. However, I keep on getting “Cannot create binding for class 'Aggregator' that is not exported by the script.” However, I do export it:
Is there something that is typically missed?
Is there something that is typically missed?
Nyes using RPC for the call. The requestID is the one that we get from the cloudflare header, which also ends up in the observability logs somehow
IJust maybe putting Terraform aside for a second, when I go via the UI and try to bind, it does not seem to see any durable objects exported in the script. I guess there is some misunderstanding from my side. What is going on here? How does one create durable objects?
1Have you added the binding to wrangler config?
MYou'll want to ensure that the Durable Object class is exported in your main workerfile
You also need to configure the
You also need to configure the
wranglerI have a question about durable object pricing with RpcTarget. If my durable object has returned an RpcTarget (allowing me to amortize multiple calls within the same RPC session) am I correct to assume that while the RpcTarget stub is alive (hasn't been disposed of), the durable object must be actively running and billing me? I have a worker that makes multiple calls to a durable object, but between each call there's slow calls to an external service. If the durable object will be billing me for the whole rpc session, my guess is it would be cheaper to break into multiple shorter rpc sessions. Appreciate any clarifications!
Awhat can be done to prevent a malicious actor from sending too many websocket messages to a durableobject? there seems to be some internal queue of incoming messages that's getting flooded (even before the requests reach my DO's code)
MYou could try the Firewall API and create a new rule, https://developers.cloudflare.com/api/resources/firewall/subresources/rules/methods/create/
Interact with Cloudflare's products and services via the Cloudflare API
MWhat malicious actor is causing the problem @Avi?
Athis is apparently deprecated? to be clear the issue is the frequency of sending of traffic. i'm looking for a ratelimit, not to block a particular actor indefiniteyl
Ait's a videogame, so people who are looking to cheat
MThanks. Yes. The new API appears to be: https://developers.cloudflare.com/ruleset-engine/rulesets-api/create/
We are using the legacy API in production at the moment. Idea is to make API call to CF to dynamicaly manage firewall rules to prevent connection from happening in the first place.
We are using the legacy API in production at the moment. Idea is to make API call to CF to dynamicaly manage firewall rules to prevent connection from happening in the first place.
Aright, i wouldn't want to prevent the connection entirely
Ajust to say, limit the number of messages being sent to X per Y amount of time
MRateLimit?
Ayes
MThere is a new built-in rate limiter here: https://developers.cloudflare.com/workers/runtime-apis/bindings/rate-limit/
We have custom RateLimit durable object here which has configurable locking settings
We have custom RateLimit durable object here which has configurable locking settings
Aooo that's cool, hadn't seen this before. although i doubt it would work for websocket messages
Myou can make a new DurableObject instance that acts a rate limiter, its very easy
Mand use custom business logic from your app
Ai don't follow. you're saying create a second DurableObject?
Msomething like:
IWhen sharding a durable object, if one instance sets an alarm, is it guaranteed that the same instance will be invoked by the alarm?
AYou can configure that timeout to be longer, i forget the exact numbers, maybe 5 or 10 min? If you have jobs that need even more than that, then DOs alone aren't the right thing you might want to look into Containers, that's currently the only way to run long jobs in CF
LYou fire and forget to offload it to another DO whose only purpose is to send fetch requests, await responses, and send them back to the originating DO. The trick is to pass in the id of the original DO so this RequestProxy DO knows who to dial up again once it gets the response. Under load, this DO never hibernates but it's only one DO not all of your others.
I'm in the process of open sourcing a lot of pieces of our stack right now. The first drop is going to be a testing module that works great with WebSockets and simulates browser behavior (cookies, origin, etc.). After that, I may port our RequestProxy DO to the open source project. I'll come back here once it's published. Any day now for the testing, rpc, and utils modules. Just in the final steps of documentation editing.
I'm in the process of open sourcing a lot of pieces of our stack right now. The first drop is going to be a testing module that works great with WebSockets and simulates browser behavior (cookies, origin, etc.). After that, I may port our RequestProxy DO to the open source project. I'll come back here once it's published. Any day now for the testing, rpc, and utils modules. Just in the final steps of documentation editing.
1Would this work:
DO A is acting as a WebSocket client, not using hibernation. DO B connects to DO A via WebSocket, DO A acts as the server and DO B as the client. Will DO B be able to hibernate, while A stays pinned to memory? In my scenario I'm already using DO A as a WS server for a different service but I want to direct data from A to B and using WS feels the best way to do it if B will hibernate
DO A is acting as a WebSocket client, not using hibernation. DO B connects to DO A via WebSocket, DO A acts as the server and DO B as the client. Will DO B be able to hibernate, while A stays pinned to memory? In my scenario I'm already using DO A as a WS server for a different service but I want to direct data from A to B and using WS feels the best way to do it if B will hibernate
BDO websocket connections as clients can't hibernate, only as servers at the moment.
1So in this instance I'd be better off having DO B act as the server yeah?
LFor DO to DO, wouldn't RPC be a better choice?
1Yeah it would be, mostly looking to reduce request costs
LI haven't done any of this myself but I believe that RPC has the concept of a "session". I don't think you pay for requests during a "session". I also believe that sessions timeout though so I'm guessing you have to sense when that happens and create a new session.
1The session you talk about would be related to stubs and RpcTarget right? I don't like having to think about whether a new stub needs to be made and stuff. Currently, DO to DO RPC requires at least 2 requests per RPC call. If I use websockets, I make one request to connect, then I can send 20 messages for the price of 1
LFair enough. I still use fetch between DOs. Someday I'll start playing with RPC, RpcTarget, etc.
Phm?
VDid workers release a new version yesterday? My service got more errors than last full week.
LCurrently, DO to DO RPC requires at least 2 requests per RPC callWhat do you mean 2 requests per RPC call? There should only be one round trip for a normal RPC call.
1Sorry I was including the call to the Worker as well
BI'm seeing some weird behavior 
happening in my Durable Objects "Live" logs. I'm seeing requests for an unrelated worker, that is a worker in a different project? It's a project that gets a lot of traffic compared to others, so I'm note sure if it is showing the traffic for all my workers or not. But there is a problem!
happening in my Durable Objects "Live" logs. I'm seeing requests for an unrelated worker, that is a worker in a different project? It's a project that gets a lot of traffic compared to others, so I'm note sure if it is showing the traffic for all my workers or not. But there is a problem!
AHas anyone else seen issues with ios 26 websockets and connecting to durable objects? I encountered this issue with one of my users. I think it might be an Apple issue, but I have only seen it once so far. They were using private relay
Apple forum thread: https://discussions.apple.com/thread/256142477?sortBy=rank
Apple forum thread: https://discussions.apple.com/thread/256142477?sortBy=rank
GI can't help but read it as pain in the rear
LLooking up the workerd codebase, I found this:
But it is hard to tell what "concurrent writes that haven't happened yet" means. Is it saying after the callback returns, the bookmark will be accurate?
But it is hard to tell what "concurrent writes that haven't happened yet" means. Is it saying after the callback returns, the bookmark will be accurate?
HI wonder if each Durable Object will come with its own R2 binding too in the future
LConfigures the Durable Object so that the next time it restarts, it should restore its storage to exactly match what the storage contained at the given bookmark. After calling this, the application should typically invoke ctx.abort() to restart the Durable Object, thus completing the point-in-time recovery.
As the docs say, works on the next restart, so you need to kill the DO for the restore to happen.
As mentioned multiple times, I suggest you always
await