workers-and-pages-help
pages-help
general-help
durable-objects
workers-and-pages-discussions
pages-discussions
wrangler
coding-help
kv
🦀rust-on-workers
miniflare
stream
general-discussions
functions
zaraz
⚡instant-logs
email-routing
r2
pubsub-beta
analytics-engine
d1-database
queues
workers-for-platforms
workerd-runtime
🤖turnstile
radar
logs-engine
cloudflare-go
terraform-provider-cloudflare
workers-ai
browser-rendering-api
logs-and-analytics
next-on-pages
cloudflare-ai
build-caching-beta
hyperdrive
vectorize
ai-gateway
python-workers-beta
vitest-integration-beta
workers-observability
workflows
vite-plugin
pipelines-beta
containers-beta
Cap'n Web discussion
Seems easy to accidentally foot-gun yourself by sharing capabilities to peers in unexpected ways. Need to be careful which scopes you are passing around.
We have a consumer portal where
We have a consumer portal where conversations (messages) are generated. We need these same conversation messages to be delivered in real time to a different portal. The requirements are:
Messages must be delivered in FIFO (first in, first out) order.
No message should be dropped....
True, I too have never seen a WebSocket
True, I too have never seen a WebSocket connection stay up for 7 days--1 day is rare, but in my thinking, WebSocket "events" are not like a Request/Response cycle of HTTP. Each message is one-way and you would never be waiting on an external fetch. A WebSocket upgrade cycle could take longer and involve an external fetch but I don't think of that as an event. That's the only part of WebSockets that involes a traditional HTTP Request/Response.
Some clarity on this would be nice, but I have to say that I have never knowingly had a WebSocket "event" hang on me so I'm not even sure why this setting is in there. Someone must have experienced hangups at some point, is my best guess....
What does it look like for you if a DO
What does it look like for you if a DO gets "stuck", I don't think we have witnessed this behavior yet?
Building Pub-Sub with Durable Objects
Can anyone suggest a potential architecture using Durable Objects in order to create a "BuddyList" functionality? The goal here is to be able to propagate status updates ( online / offline ) at scale to all users belonging to the BuddyList.
Our current design uses a DO instance per user and our
setStatus() DO method utilizes a fan-out with batch concurrency in order to iterate through each "buddy" of a user, fetching the buddy's remote DO instance in order to push the status state.
Does that make sense? We've found the fan-out is brittle, timeouts happen, probable issues with fan-out storms. Retries with back-offs aren't great either. We don't really have the luxury of a status update failing....hello everybody, I'm currently in the
hello everybody, I'm currently in the process of migrating a big part of my existing stack to cloudflare durable objects. The only thing that is concering to me, lately is that I have seen several reports from users on X lately noting unreliability.
Are these just disgruntled users that perhaps do not even fully understand how DO's work, or is there validity to what they are saying and should I not be building critical infrastructure on this? I expect to be processing millions of requests on a daily basis....
I'm trying to run both wrangler projects
I'm trying to run both wrangler projects with -c but the UI cannot connect to the DurableObject defined in the backend worker (locally)
how do i avoid this kind of memory error
how do i avoid this kind of memory error then? each individual request does not cause an out of memory error but when multiple hit the same isolate they do
Hey! I have a general architecture
Hey! I have a general architecture question - I have a bunch of always on, always connected iot devices that I need to be able to send commands to. For security reasons, we don't want these to have open endpoints do we're experimenting with having them open websockets to durable objects. We Jeff to have a UI be able to send and receive commands from the devices, so have started opening websockets from the UI to the durable object worker. It seems a little brittle, as we sometimes lose connection to the devices. Does this sound like a reasonable architecture, or is there a better way to approach this project?
Additionally, we'd like to monitor the connections but each device is attaching to its own DO. Any suggestions on how to monitor across a collection of them or a better way to do it?...
i have a project that's using durable
i have a project that's using durable objects in various workers environments, which was originally set up with the durable objects attached to their own worker. i recently tried to consolidate the durable objects to a single worker, and when i tried to set up my wrangler file to transfer the durable object storage to the new worker, the transfer seems to have failed. the durable objects don't have any data in the new worker. here's how i set up my DO migrations. did i do something wrong? i wasn't able to figure this out based on the documentation.
```
"durable_objects": {
"bindings": [
{...
Something odd is going on. About 2-3
Something odd is going on. About 2-3 weeks ago we started seeing occasional
1006 disconnects from websocket clients. Any ideas why this behavior may have changed?
In an attempt to mitigate we added:
```js...Unit/Integration Testing WebSockets
Hi, đź‘‹
Does anyone have a good reference for unit/integration testing websockets with durable objects? I have found examples/documents for request/response, but I haven't found a good example using websockets....
DO Placement Debugging
anyone have ideas why my DOs are being created in England (LHR) when I'm 6000 miles away in california?
really the docs just need to be better.
really the docs just need to be better. there are so many details here that matter that are undocumented
Lifecycle of a Durable Object
There was a discussion around this recently. The consensus was that outgoing WebSocket connections prevented the DO from entering the "Idle, In-memory, & Hibernatable state" eventhough it's not listed as one of the three conditions that would do that in Lambros' awesome lifecycle diagram: https://developers.cloudflare.com/durable-objects/concepts/durable-object-lifecycle/. I don't think we ever got a definitive answer on that thread. Someone is going to have to run an experiment.
Wanna get some thoughts on how to handle
Wanna get some thoughts on how to handle this use case:
I need to synchronise a a countup timer between two types of clients. Currently, the clients poll an API which gives a datetime to signify the timer start, when field is changed then timer ticks up second by second on each client independently. Over a 30 min period these two diff client types drift up to a couple mins from each other, due to differences in how each works. If both clients were to connected to a hibernated DO WS, what would be the best way to keep a timer synced? Call an alarm() every ~1000ms and send the current time value, or continue to let each client handle on its own? Can I rely on a self-setting alarm to be 'roughly' accurate over a particular time period (for my use case, within 10 seconds drift over 30 mins would be acceptable)
Not sure if this explanation makes any sense at all, I might try and make a diagram later lol...Hey Wes. We aren't using Party Server
Hey Wes. We aren't using Party Server here; however it sounds like you are possibly awaiting the fetch result inside the realtime path. Is the
await fetch() inside the onMessage handler and sibling to the broadcast() call?
You should be able to resolve this by moving the fetch to another codepath or ensuring the fetch isn't blocking the broadcast....Merging Actors and Agents
I liked the way it has some things like persistant internal vars, how it handles migrations, etc. Like I wanted to add a versioning table for my state to my agent, now I have to handle that seperatly or store things I dont want to expose in the state to the state if I want to keep it easy