Saw

Internal error in DurableObjectStorage put() operation

for the first time today. Any idea?

Just one time, or repeatable? There are a number of rare issues that can cause random errors. They get reported to us automatically and we're always working on reducing the rate of these.

Only saw it once

The question was about a request from a DO to a regular stateless worker. The regular worker can run anywhere and, at present, will always run on the same machine (though that could change).

Is that what @User meant? I thought it was the response from DO back to the bundled worker via stub.

I wonder if you get automatic reports of the deadlock issue? This is honestly the only deal-breaker type issue I've seen, since it cannot be worked around without force uploading another script, and it causes all callers including readers to immediately hang. started seeing it over last wkend: https://discord.com/channels/595317990191398933/773219443911819284/860937469683302401

Ah, maybe I misunderstood. But yeah, any communication that stays in Cloudflare's network is exempt as I understand it. (Disclaimer: I am not deeply involved in pricing...)

Hmm I wasn't aware of that problem, but that might just be me, let me check with the team.

I am talking about the data transfer happening when a Durable Object responds to a request made a Bundled Worker:

Request:
Client -> Bundled Worker -> Durable Object

Response:
Durable Object -> Bundled Worker -> Client
                ^This

That wouldn't incur a charge, but like Kenton said I'm not a billing expert either. The tl;dr is that DO egress billing is only for subrequests the DO makes outside of Cloudflare

It appears that storage hangs aren't something we were aware of. We're going to add a timeout so that objects get un-stuck and we get an automatic report of the issue.

Perfect, thanks - I'm only doing sequential

.put(many)

calls with no explicit tx. I could switch to an explicit transaction if I could provide a custom timeout to the

.transaction

method, or if it just times out magically in something on the order of seconds that would be great too

so i finally get typescript webpack (ts-loader) to export a esm to get past some errors

and then

the problem might be that webpack still insists on keeping harmony imports and exports while also doing esm exports (with the regular

export

syntax) but I can't say for sure

ok it looks like that was actually due to workers sites

this was when deploying a fresh DO + worker with a

[site]

tag in wrangler.toml

removing said tag and its contents allowed it to go through

then I added it back and it's fine

hey folks, FYI we are rolling out a very big internal change to the Durable Objects storage API this week -- initially in PRG tomorrow and other colos Wednesday or Thursday. The change should have no effect except to make things faster, but please let me know if you see anything fishy. (We'll have a blog post with technical details later on.)

Should i build my webrtc signalling server using Cloudflare worker or AWS APIGateway... i can't seems to understand the cost for Cloudflare worker..

for me it depends on how busy your channels are. the more devices on a given channel concurrently the more Durable Objects make sense financially.

but if you have a signaling server with one idle client connected nonstop, DO becomes pretty expensive (under current theoretical billing, i know the CF team is looking to tweak things to make this use case easier.)

I've finally got around to trying this but I'm not sure how to make the traces work with DOs. Is there a wrapper for DurableObjectStub so that its request() passes the trace fields?

No, the DurableObjectStub should be automatically instrumented. Can you DM me the snippets that instrument/wrap your worker and your DO?

sorry when I have to jump in here, but as mostly only workers talk to DOs, and as you said that's on the CF network and egress there costs nothing, is the only charged egress from DO then via websockets? Or did I misunderstand something? Also thought only workers can talk to DOs, as this was a statement in the beginning, now with WebSockets that seems to be the only "direct" egress outside CF from DOs

The only egress charge would be a DO making a subrequest outside of Cloudflare. Websocket communication still technically flows through a normal Worker near the user.

Hey folks, we have a PR to wrangler open to allow adding migrations in

wrangler.toml

(tl;dr no more

--new-class

on first upload for DO projects!) https://github.com/cloudflare/wrangler/pull/1992 We'd appreciate some testers, if you want to play around with it testing instructions and some docs are in the PR description.

Small questions: 1 - Whats the expected latency to retrieve a value from DO storage? Here appear to be the same as the KV (10ms) 2 - Will the value (32kb) limit be raised only after (if) the end of the beta? 3 - DO storage has any cold/hot call (cached) like KV? Read the same key again should be faster? 4 - At some point we will able to "read" data from other DO (in the same datacenter at least)? I have a user case that i need to process a lot of data across few DOs, and i need to put that value inside the KV to share data.

The tricky things about small questions is they can lead to big answers 🙂 But let's see how far I get: 1 - I wouldn't expect latency for DOs to be very different from a hot KV read. They are all from the same or near dcs. 2 - I haven't heard anything about an increase of the limit. As always, it really helps us if you could tell us why you want the limit increased. What can you do if the limit was increased, but isn't possible now. 3 - I not 100% sure, but pretty sure that we wouldn't expect to see any cold-start behaviour. I haven't noticed it in my testing at least. 4- Right now the only way to "read" data from another DO is to fetch it with a regular request. I doubt we will have anything in the future where it will be possible to directly read the data from another DO instance beyond that. It is possible though that you could remove a bunch of the reasons for those requests by architecting/modeling your DOs differently. If you want DM me and I would love to take a look 🙂