One non production example is to call some system without spin-up aws/gce vms in some particular region/place just to do that. If the intend is see the behavior of those call on other regions, writing worker code maybe easier.

But im sure that has more real and userfull user cases for that.... Automatic is nice, but sometime "manual" fills the gap....

Hey, is it possible for a durable object to know what string was passed to

env.CLASSNAME.idFromName("...");

in order to be invoked?

I'm probably missing something obvious here 😛

I think you can do:

const id = env.CLASSNAME.idFromName("name")
console.log(id.name); // "name"

...and potentially:

class DurableObject {
  constructor(state, env) {
    console.log(state.id.name);
  }
}

...but really not sure if name will be defined in that 2nd example

Nope, although this is a common request - has something to do with the fact that the name is input to some sort of hashing function on the caller side. You can, however, pass the name string value down in the stub.fetch call, for example in a custom header.

Interesting, thanks!

Hmm, never seen these headers before:

cf-int-ctrl-1: {\"ewLog\":{\"cpuTime\":763,\"status\":\"ok\"}}

where are you seeing that? In a DO request?

DO response - i wish all DO fetches had this (for the cpuTime)

Hi. I'm seeing some odd behavior and I'm trying to determine if maybe I'm being rate limiting. I have an app that sends a lot of requests (~100 http posts per second) from one client to a durable object. I'm on the paid plan. It runs fine for awhile with requests taking on average 200ms, then for reasons that aren't clear, suddenly goes off the rails with requests taking dozens of seconds. After awhile the worker recovers and goes back to normal. It's very possible I'm doing something wrong, but I wanted to ensure I'm not being rate limited while I debug in parallel. See https://wormhole.app/52qPE#KcOkO1zB9LkaLE8wF5CZZA for demo.

The worker is https://replicache-worker.replicache.workers.dev if that's helpful.

How are you retrieving that value? In the Worker that has the stub? In the DO?

wrangler tail

?

it's included in the headers in the

Response

returned to the stub - note I think it only happens on responses to

upgrade: websocket

requests initiated by the worker -> DO

You aren't technically being rate-limited, but you are sorta limited in what you can send to the DO 🙂 Because one DO is one event-loop, it is not possible to send more than 1/ per second.. So if the average CPU time of your DO is 10ms, you can indeed only send ~100 requests/second to that DO before requests start backing up. And that is probably what you are seeing. A burst of requests backing up and being queued for a while before they can be handled by the DO. And one that burst is gone, things go back to normal again..

yeah that makes sense but it doesn't really explain what i'm seeing for a few reasons: 1) I frequently see this simulation run for a long time before I start getting slow responses. The amount of time before I start to see this behavior is highly variable (this also sort of rules out rate limiting, but I just wanted to be sure) 2) I don't think my DO request are taking anywhere near 10ms in the normal case. But it's hard to know because timers don't work in worker environment :).

Well.. the things is that you can be just below saturation limits and it can take only a small deviation to put it over the limit. And once you have a run-away process, it can get bad really quickly. So just 1 or 2 requests taking longer, a HTTP request timing out etc.. can tip a system that was stable before into very unstable territory..

And also, timers sorta work in Workers. They get updated after any IO. So if you do a

setTimeout(() => { const durationMs = start - Date.now() }, 0)

just before you return a response.. you can get a reasonable approximation of how long that request took

Hm yeah I get that. I still think something weird is going on. But good to know it’s not rate limiting.

Alright, thanks.

Do calls to the storage api count as “io”? I would like to measure how long eg get, set, and transaction() take

Yes, that should be the case

Hi, @User @User ! Still no luck. I feel the day we need to change something in our production is coming 🙃 . Is there any ETA? This bug blocks DO development/usage significantly (only root directory is available/no way to structure project files). Just to refresh the context: it's impossible to import any file outside the root directory inside the "modules" format project, which is the new default/required for durable objects. This functionality is broken on CF's side for about 2-3 weeks now.

Hey Dmitry, I have no familiarity with this. @kenton will be starting his day soon, so I expect he will figure out where this is at and come back to you.

is there any tool to test locally with the ability to make request on localhost ?

https://miniflare.dev is a great tool

perfect, thanks @User

@User We're still working on identifying a root cause. Based on your description of your project, it sounds like you're not using a bundler in your project? In the meantime, if you can switch your project to using a bundler, you can maintain a nested project structure but it'll upload as a single module. This should let you work around the problem for now. Our Rollup template should be a good starting point here, but other folks in this discord have had success with esbuild as well.

FWIW: Can you just bundle you project? Im using the ESBuild target to es2021 using the esm format.

ops... i just see the matt response now.... but yes, bundle should solve the problem here.