You will be missed gl to you!

Hello, I'm trying to use the environments feature of wrangler for the first time and I am a bit confused as to why durable_objects bindings are not inherited (https://developers.cloudflare.com/workers/wrangler/configuration/#non-inheritable-keys), but durable object migrations are inherited "The migration list is an ordered array of tables, specified as a top-level key in your wrangler.toml file. The migration list is inherited by all environments and cannot be overridden by a specific environment." (https://developers.cloudflare.com/workers/learning/using-durable-objects#durable-object-migrations-in-wranglertoml).

Does the cache API called inside a DO (if its even possible) always pointing to the same datacenter to create a free and eventually consistent cache ?

Yes, you can call cache API inside a DO and will point to the "cache" from that particular colo; And is pretty consistent, you can write read again immediately on the next request that will works very nice as expected for for almost anything on the CDN side that also does a pretty good job on avoid call multiple times the proxied server.

nice, i would just pay for 2 requests instead of 2 + 1 read

most of the times

The rules will be the same as the CDN... Will keep the data until needs to delete for whatever reason.

which is fine tbh

I can delete it manually when a state change happens

and rewrite it

You can also use a separate cache namespace instead the default one; Most of the times i use the

await caches.open('custom:cache')

Well, it should, as long as your DO doesn’t switch colos

bro you made this poor guy quit his job 😭

Well you will be missed here. Thank you for taking good care of the community and answering us patiently. Best of luck for your future endeavors!

I'm having a strange issue with a DO usage. A DO with websocket is reporting usage of 7K to 8K GB-sec per 24 hours for the last month, which essentially means its running for 17 hours a day, whereas I expect it be to running just XX mins a day. This is in testing, not released to production, barely used, and has just a handful of objects. So, am I missing something. And how do I drill down and check this usage whether its accurate, which object is actually running for long? Or any other pointers / help to debug this.

i am storing users who are currently in a chatroom (no websockets) in a

this.users

variable in the DO class. if two users are doing post requests to the DO at the same time, sometimes it doesn't show all of them is it because that memory is wiped before another user can send a request to the same DO namespace

you shouldn't/can't rely on storing variables on the DO like that. why not use storage?

idk when the user leaves so was hoping to put it in memory and have it clean up after a while. probably not a good idea

Having it in memory can disappear at any point, so that won't be a good strategy if you can't lose the data, even for a couple of minutes. Perhaps you can use DO storage, and then an alarm to remove the old ones automatically after a while?

hmm yeah this is the best way

8000GB-sec is 17 minutes. Also highly recommend giving a try to the new hibernation API if you aren’t so that objects are not active the entire time a web socket is connected but only when processing messages

Can multiple workers call a DO if I don't use storage? Or will it have to wait untill a fetch is returned before the next do can execute? Or can multiple instances of a worker use the same DO async? Cant figure it out using the docs..

Not sure where you are getting your numbers from. 1 DO running continuously for 30 days = 331,776 GB-s, which means per day = 11,059, ie per 24 hrs. Each hour uses 461 GB-s. And so on.

Ah actually I see I’m doing the wrong conversion should be *8 for that way lol. But my point about web sockets was still accurate

Yup will try the hibernation API, but even without that - I have a 5min timeout on an idle socket connection, after which the socket is closed, so I dont see how the DO can be active continuously...

So wait, does the DO have to send heartbeats to keep it open?

Yes, I saw those JS examples - but in rust I am not sure what sync/async equivalent methods I can use. Maybe I need to use some block_on() primitive, but not sure if available in the runtime used in Workers…?

first attempt:

fetch: (request) => router
    .handle(request)
    // transform unformed responses
    .then(json)
    // add CORS headers to all requests including errors
    .then(corsify)
    // catch any errors
    .catch(error)

second attempt:

fetch: (request, env, ctx) => router
    .handle(request, env, ctx)
    // transform unformed responses
    .then(json)
    // add CORS headers to all requests including errors
    .then(corsify)
    // catch any errors
    .catch(error)

third attempt:

async fetch(request, env, ctx) {
   await router
      .handle(request)
      // transform unformed responses
      .then(json)
      // add CORS headers to all requests including errors
      .then(corsify)
      // catch any errors
      .catch(error)
}

How do you do it? Wouldn't it flood your local connection ? Or you have multiple VMs that you run this from. Making a thread so it doesn't clutter the channel

If you're in a

webSocketX()

handler then the websocket you're given through the function arg is obviously hibernatable. If you get your websockets from

this.state.getWebSockets()

, you also know they're hibernatable. However, if you're saving them in some property on your DO I figure you could lose track if you use both regular and hibernatable ws in a single namespace. Just want to see if any of y'all have an opinion 🙂