and when did this start for you? (in UTC time, if possible)

Assuming you mean DO instances rather than DO classes (this is the only class I have atm): The logs would suggest all of them, as I've not seen any successful log patterns yet. But I'm using the web interface because this project predates wrangler DO support, so I could be missing some since the interface is tough to scan. Anecdotally: A new DO is created when I refresh the app. I have not been able to get a DO where network requests succeed, and other users have reported the issue (who'd have their own DO instances).

FWIW: The price model is not really defined yet. Your observation is one of the possible scenarios. So, if you API server is already on the worker you cant compare using the initial request to the worker itself without do the same using the (for example) the lambda price. Also, you can use the worker bundled to call the DO, or call several DOs, or... other things. I dont really know, but CF can (for example) waive the computer time of the worker waiting a DO and only charge the DO computer time (for each one), the same for the request... Time will tell...

It was called to my attention at 8:30PM UTC if I did the conversion right 🤣 (1:30PM Pacific). Unfortunately and shamefully we do not have good logging for this service as it's a bit of a toy (though one that has increased in importance lately), apologies, so no way to know if it started earlier

Thanks for replying - very good points. 🙂

I thought that was changed recently?

oh wait no it was just the subrequest limit that got bumped

hey! so the number we're specifically referring to there is read cost for DO ($.20 / million) vs Dynamo ($.25 / million). We didn't include the request charges for your DO or for your Worker, since both of those can (and often do) run meaningful compute. If this ends up being expensive for users, it's possible we'll revisit our pricing or offer ways to query the storage API directly. Once we're out of beta, we'll work on getting DO into the free tier so that there's a lower barrier to getting to play around with them.

Hey Greg, thank you for answering that for me. I understand. Maybe similarly to what you said, it would be nice if the request cost of the Durable Object itself was subsidised, that way we don't end up paying double (internet -> worker ($0.15) -> durable object ($0.15) for just a request cost. Compute costs are fair as that proportionate to what you do on them. But blanket $0.15 / million on both the worker and the durable object, limits the use cases of them, which goes against being able to use the power that durable objects brings, for some projects.

I definitely hear you - we can take a look at how far we can reduce that charge once we have the system out of beta

Sounds good 👍

Just got:

TypeError: The Durable Object's code has been updated, this version can no longer access storage.

- but I haven't deployed this object's code in days 🤔

I wonder if it could be related to Cloudflare updating the servers/code behind DO´s

Since it's still in beta

Did you possibly start or stop

wrangler tail

? That will also cause that error. Otherwise, that's weird, that error should only happen when you changed something.

Not on the script in question, just two other scripts in the same account that don't use DO. In general, should we expect that error to be thrown as soon as a tail is created or deleted on a script containing a DO?

The error happens if the code is updated while a request is in the middle of being processed. Since we want to guarantee only one copy of the object is running, we have to cancel the request in order to restart the object. We'd like to come up with a gentler way to do this, but some disruption is unavoidable. Ultimately the best solution is probably to design your code with some sort of retry mechanism when a request to a DO fails -- retries are an important part of any distributed system.

With all that said, applying a tail to some other script really shouldn't cause objects to restart. That sounds like a bug.

So is the DO code considered updated as soon as there are any tails against it? And updated again when all active tails expire?

Yes, very roughly speaking,

wrangler tail

causes some code to be injected into the worker so that it sends logs somewhere. Because it's a code update, the durable objects get reset. We could probably fix this with some engineering effort.

Do durable objects share the same cache as workers in the same colo? I tried manually adding cache results from a durable object and retrieving it from a worker but it doesn't seem to give any cache hits.

They do, however: Technically, durable objects always run on behalf of your workers.dev zone, not whatever zone received the original request. This is because you could have the same worker running on multiple zones, and it would be confusing if the same object could live in multiple zones at once. So they all live in your workers.dev zone, since that's account-wide. The cache is segregated per-zone, so your regular workers will only see cache changes made by a durable object if your regular worker is processing a request for your workers.dev zone.

But in your *.workers.dev zone, caches for Workers are not enabled, right? 😅 @kenton

The cache API should work for workers.dev zones AFAIK

Only Workers deployed to custom domains have access to functional Cache operations.

(https://developers.cloudflare.com/workers/runtime-apis/cache)

Also after some experimentation I'm getting 0 cache hits (cached only used within workers on *.workers.dev zone.

Huh, that's news to me but I suppose it's probably true.

pretty sure I'm getting cache hits on *.workers.dev 🤔

I'm essentially doing this in my worker

ts
        const cache = await caches.open(`cache:key`);
        let res = await cache.match("http://my-do/info");

        if (!res) {
          res = await stub.fetch("http://my-do/info");
          const cloned = res.clone();
          const response = new Response(cloned.body, cloned);
          response.headers.set("Cache-Control", "s-maxage=30");
          await cache.put("http://my-do/info", response);
        } else {
          console.log("Cache hit.");
        }
        // ...

I never seem to get

Cache hit.

in production, e.g. when running Miniflare it works. Could it be the way I generate the cacheKeys using a simple string instead of actual request?