ooo interesting, is there a dashboard, or is it just a data store with an api?

the latter, but it's relatively easy to hook up to grafana (in the docs) or a custom solution https://developers.cloudflare.com/analytics/analytics-engine/

Yes, that's correct.

sync()

does what you would want it to do. 🙂

it waits until all past writes are durable. This is the same wait that blocks outgoing messages from the DO by default.

@john.spurlock Just catching up here and was surprised about the keys modified in a transaction limited to 128. A few questions: 1) Is a "transaction" here a single call to this DO's fetch()? and 2) Assuming "modified" means storage.put() or storage.delete(), is there a similar limit on the number of storage.get() calls?

I'm running a

wrangler dev

(hosted) with workers and durable objects on 2.8.1 and getting this random

✘ [ERROR] Uncaught (async) Error: internal error

that I can't seem to find. I've try/catch'd everything (triggered from an alarm fetching another worker) and nothing is throwing that error so I have to imagine that is something in wrangler. Is there any way for me to check that? This is happening when I enqueue an alarm from within another alarm trigger.

I'll also note that this error doesn't seem to be coming from anything, all functionality is working as expected...

ok wait this is the dumbest issue ever... if I increment the alarm time I set by 1 I get no error?

So the sequence that prevents the error is: 1. Set alarm for time X 2. Another immediate alarm is triggered by a fetch 3. That alarm sets alarm for time X+1(ms)

if step 3 is just

X

for the time, it throws the error

Suuuuuper weird and not very comfortable with why that is... but regardless I think I'll add the +1 so the error goes away and DO alarms aren't perfect to the MS anyway... still super weird since everything is working as expected

fwiw you can get around the transaction limit by implementing something like innodbs undo logs https://www.alibabacloud.com/blog/an-in-depth-analysis-of-undo-logs-in-innodb_598966

I’m having a hard time wrapping my head around the pricing for durable objects. Is there a good reference for doing back of napkin math to price out a durable object?

Just want to thank the DO team for fixing the long-standing issue of large request bodies taking ages to read inside a Durable Object! Still seems to take >500 ms to

await

a 10MB body in a DO (compared to less than 50 ms in a regular Worker), but it's a lot better than the 30 seconds it took previously 😅 https://discord.com/channels/595317990191398933/773219443911819284/964573311382220800

Say I have a durable object that represents the payment flow for a user's order. I want the user to be able to subscribe to a web socket to be notified as soon as the order has been processed. Would it make sense to have a single separate object responsible for the websocket connections for all users, and have the order objects communicate with the websocket object on completion?

This would avoid paying for lots of separate long running workers, instead having a single long running worker, and the rest short lived and using alarms

I would use pub sub for something like that, though still in beta and no pricing info atm. It also seems to be that DO will be getting some updates in regards to pricing eventually so it may be fine in regards to a socket per order. I wouldnt have a single object for all users though as a single object can only handle so much load and after like 100 users you will probably start seeing some issues

@Unsmart | Tech debt oh interesting! hadn't heard of the pubsub offering. In my situation performance isn't an issue. I'm trying to build a robust solution for a low traffic use case.. so not really making use of the scaleable aspect, rather just the durable aspect, and the ability to not have to worry about race conditions etc.

although I did have the impression you could have many more than 100 websocket subscribers if they were low traffic and weren't all connecting simultaneously, is that wrong?

ah, this is the post I was thinking of, but it doesn't really mention any numbers https://community.cloudflare.com/t/durable-object-max-websocket-connections/303138/5

I'm guessing Server Sent Events would be basically identical when it comes to max connections?

personally i’d assume so, and maybe worse because unlike WS i don’t think there’s a way to get notified when a client disconnects.

I've been seeing this error sometimes seemingly when accessing durable object storage, any idea when it happens? how many is too many reads? > Your account is doing too many concurrent storage operations. Please back off and try again later.

Hello! I'm trying to understand how to use Durable Objects with Pages Functions. Is it necessary to create a Worker in order to use a Durable Object, or can I instantiate a Durable Object directly from within a Pages Function? In the Bindings options for Pages it seems possible to assign a Durable Object Namespace directly to a Page without using a Service Binding. How is this intended to work? Is there an example somewhere? There don't seem to be any documentation regarding this.

You do need to create a worker for your DO, yes

Functions can't currently export their own durable objects

Ok, thanks! But then what is the use of Durable Object bindings for Pages? Seems redundant if I select my DO Worker as a Service binding?

if you do a service binding it would cost more because you have to do a worker request and a DO request

if you bind to the DO directly you just do a DO request

Ok, now I am confused. I need to do a Worker in order to use DO. So... every worker that uses a DO should be added as a DO binding and not a Service binding?