Not personally used DOs before so I wanted to make sure my assumptions were all correct

Oh don't forget, no TTL in DOs, so you'd need to tag them with a timestamp and clean them up (if you want)

Or else you'd always read stale DO "cached" data

Oh - interesting, thanks for the pointer

Any plans to add a way to specifically say “even though my closest colo is SJC, make my DO in IAD anyway”? I know you can fudge it with a proxy, but that’s kind of clunky

Or #960679900929478666?

Yeah if you want/need to proactively clean them up. I was thinking more of putting a timestamp in with the data, so on DO read if it's >1min old you have to DO talk to D1 and update the value, or something

Yeah soon hopefully

Fwiw I currently store them for 2 weeks, then let it revalidate - could do the same on a DO I imagine (just have to check the timestamp myself)

What is the arraybuffer equivalent of "await response.text()" for DOs? I am having to collect the Stream data and convert as it is...

Maybe a kind of dumb question: if I want to completely delete a durable object, do I just deleteAll() on storage and just wait for the object to spin down? Do I have to do anything else?

thats all

Hey, all. Not the most efficient can Durable Objects be published without wrangler? **Context**: whenever I make updates to a worker, I build the project using

wrangler publish --dry-run

to a

dist

directory and then send the built script to Sys Admins who upload the script manually using the CF dashboard. We turned on Durable Objects and I do a named export of a class as the Durable Object but it doesn't show up as a binding.

Hi, I believe you can publish DOs, and now alarms are standard so that's not an issue, however the migration needs to be applied via wrangler.toml, so at least once you would have to publish directly from

wrangler publish

- and I'd recommend to do so in all cases, you get a lot more control over the project that way See https://developers.cloudflare.com/workers/wrangler/configuration/#source-of-truth and https://developers.cloudflare.com/workers/wrangler/configuration/#migrations <-- you'll need to add a

new_classes

migration as shown here

Ah! It worked. Thanks a lot. You're right. The Durable Objects configuration wasn't being passed along when I built the script so the bindings weren't available. I totally agree with you on using

wrangler

and being able to version the

wrangler.toml

file.

Good morning! I'm aware that the worker trace events logpush logs for

alarm

handlers are not implemented fully yet (the record is there, but no detail), but I'm curious if each unhandled alarm error will cause an "outcome" = "exception" record (ie for each retry, up to six), or just the final error (out of retries). From what I'm seeing, I'm pretty sure it's the former, but would like confirmation from someone orange, thanks!

Yep, the former

Any updates on that ?

I was wondering if the DO alarms that are triggered through

do-taskmanager

will also increase the count of workers triggers. If I have 10 DOs with an alarm attached for each one, would this mean that also the workers trigger count will increase of 10 adding up after they are all invoked?

Silly question. I have a DurableObject that needs to make a

fetch

request to the

stream/live_inputs

API. I added my

API_KEY

to my cloudflare worker. But there doesn't seem to be a way to pass the

env

to a DurableObject... How do I get my API_KEY into the durable object? Should I include it in the incoming request as a header?

all the env values on your worker are already available to the DO in the same way as the normal worker

well kind of the same way, its the second param of the constructor

Oh 🤦‍♂️ I was trying to add it to the

fetch

method

Ignore me - thanks for the help!

how many subrequests can a DO do when its running 24/7? 1000?

or, how can I archive more than 1000 fetches in a durable object

you can: - use websockets within the DO - retrieve the list of fetches to carry them out, batch them up and then send them to the websocket. The receiver can then work through the batch - use queues - use a DO alarm - create an internal queue (who's operations are protected by blockConcurrencyWhile) and then pop X requests for each alarm...

The durable object's outgoing subrequest limit is topped-up every time it receives an incoming request, WebSocket message, or alarm. So if you are receiving incoming traffic then your outgoing limit should be continuously reset. If you aren't receiving incoming traffic, then the DO will shut down after a short time.

What does a always busy DO cost per month? about $10-12 is what I calculated, am I right?