$0

** whoops non idle

busy

~$4.21

I saw this in the docs 1,000,000 seconds * 128 MB / 1 GB = 128,000 GB-s 128k gbs = ~$4 and a month has about 2.6M ?

128k gbs = $1.60

aah whoops, $12.50/million GB-s not 12.5 per 400k

$12.50 / 1000000 = $0.0000125 per 1 GB-sec $0.0000125 * 128000 = $1.60

okay that saves everything, thanks a lot. was worrying about if DO is the right tool then :b

My only problem is despite the cost be low, like $1.60 or $4.21 im always charged but the full million GB-s; So if i use 500GB-s or 900GB-s i aways pay the full $12.50; The same for requests, always billing on $0.15 increments.

For my company is no problem, but for my personal projects thats not nice.

Can you access D1 from within a durable object? I see plenty of docs on using it from within a worker, but not sure how I bind it to my DO

Q: is the following error message we saw today around 11:10AM UTC-7 potentially something we're doing wrong on our end or perhaps something transient on the CF end?

Unhandled exception in fetch Error: Durable Object namespace binding is unavailable.
    at bn (index.js:393:19)
    at async lr (index.js:517:12)
    at async o.fetch (index.js:715:35) {
  stack: Error: Durable Object namespace binding is unavail…js:517:12)
    at async o.fetch (index.js:715:35),
  message: Durable Object namespace binding is unavailable.

The line of code throwing is:

const objectID = await fooDO.newUniqueId(options);

The fooDO previously existed and worked fine, we were `wrangler dev`ing some new changes we were working on. It happened reliably for 5-10 minutes then stopped (that line stopped throwing).

That seems odd. Do you happen to know what colos you typically hit? Or what part of the world are you in?

The command was run in Tuscon, AZ. I'm not sure what colos we usually get routed to there, when my guy is back online I'll have him run a script to find out.

If they happen to know the colo when that happens I’m curious

We won't know the colo it happened in, but I can tell you where his request gets routed when he runs the command again this time.

Just trying to remember, is idFromName or idFromString faster? As in, should I store the name of a DO, or it’s stringified ID for fastest recall

string for sure

but IIRC it matters most when accessed immediately after creation

just saves you a lookup

Guess I'll go with that then, since I am aiming for fast speed at all times, so reducing lookup time is nice

When we re run the worker is in LAX and the DO is in SJC.

Turns out that D1 is broken inside DO when using

wrangler dev

https://github.com/cloudflare/wrangler2/issues/2335. Does anyone know if it works in production?

There's already a comment from a maintainer saying they're looking at a fix -- I'd imagine it doesn't work in either local or production

> Currently, Durable Objects do not migrate between locations after initial creation. Cloudflare will be exploring automatic migration compatibility in the future. > https://developers.cloudflare.com/workers/learning/using-durable-objects#object-location is there any more information surrounding this or its progress?

Best answer we can give you at the moment is

I have a durable object that is continuously "searching" for something, e.g. retrying a request, until it finds something with a limit of like 100 retries (with some sort of back-off). I'm getting the following FetchError thrown within that Durable Object:

FetchError: Too many subrequests. Workers can make up to 50 subrequests per request.

. This limit shouldn't count for durable object, right? I'm getting this in

wrangler dev

btw.

No new info yet, but if you can explain what you need/want it's always useful to have more info

I would have expected a limit of 1000 I think? I wonder if the 50 vs 1000 is an issue with dev? Either way these limits are topped-up per request or WebSocket message that the DO receives. DOs are still currently "request-driven" and so they need some amount of incoming work for us to let them continue doing work.