Cloudflare Developers

CD

Cloudflare Developers

Welcome to the official Cloudflare Developers server. Here you can ask for help and stay updated with the latest news

Join

OK I have read through the last three

OK, I have read through the last three months of discord and searched, and am still coming up empty. I am using itty-router-openapi to serve paths. I have only been getting KV pairs and that seems to work just fine in my worker. I would like to get a Durable Object called User: ```durable_objects.bindings = [...

I cannot figure out this typing error

I cannot figure out this typing error
No description

IIRC there is no way to launch a promise

IIRC there is no way to launch a promise in a durable object (from a request) in such a way that does not block a response? For example I am trying to ship logs from a custom logger async to loki, but i don't want that to block responding to a request

Hey I think someone is attacking our DOs

Hey I think someone is attacking our DOs:

```

``` const MINUTES = 60 * 1000 export class NanoID { constructor(state, env) {...

Yeah that will be the request it came

Yeah that will be the request it came from not the DO colo. Right now it is possible to do /cdn-cgi/trace, but there has been a discussion about that being removed so it wont be possible to tell.

DO + pages

You need a second Worker, also running dev

That code base is really hard to follow

That code base is really hard to follow, can you be more specific on where the problem is?

I am trying to run a background promise

I am trying to run a background promise to drain logs in a durable object that looks like this: ``` const res = new Response("broadcasted") logger.Drain() return res...

TransactionalDOWrapper suggestions thread

Cool idea šŸ‘ ! I recommend checking out do-transactional-outbox for an even stronger model of storage consistency. For your example in the blog post, I'm not sure if by using awaitĀ you potentially eliminate (some of) the benefits of caching state in memory, let me explain. I recommend taking a look at state.blockConcurrencyWhile: call it in your constructor, no need to await it (you couldn't anyways, since constructors have to be sync), but it blocks further requests until you finish with your hydrate function. Then, you can always be sure that this.name and others will have been populated whenever your request comes in via fetch, so you can simplify your code further - eliminating another potential concurrency issue, where you're awaiting the hydrate promise, and another event handler starts executing, calling hydrate again, and potentially reading from storage once more as this.hydrated may not have been set to true yet (knock knock, race condition, who's there type situation), and then you overwrite name from the second call....

I have a question how the memory is

I have a question how the memory is managed for DO: Ā« If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory. Ā» If we have 2 DO instances of the same class that running on the same colo, and share the same 128MB of memory. Imagine one currently uses 100MB and the other 27MB, then the second increase his memory usage and so we reach memory limit of the 128MB shared memory. What's happening? Is this second instance is killed and recreate automatically in exactly the same state on another 128MB VM of the colo ?...

I ended up using `env DO CLASS get key `

I ended up using env.DO_CLASS.get(key), is that okay or should I use proxyDurable?

Really weird What do you get if you just

Really weird. What do you get if you just console.log(request.url), without any formatting?

DOs cannot store values as large as KV

DOs cannot store values as large as KV. Limit of 128KiB per value vs 25MiB. DOs are also not replicated like KV is (KV has 2 central stores, one US one EU). And of course there are different throughput limits KV has unlimited throughput (other than write 1 per second to the same key). DOs limits as an exclusive key value store should be pretty high for both write and read (you can extend read far beyond write if you use the cache api as well). With DOs I would also make sure you are using multip...

I was just hit with a much larger than

I was just hit with a much larger than expected bill, suggesting crazy high DO runtime... yet looking through each project, and each DO, I can't find one that could even be close to being the culprit. Is there a way to diagnose where the spend/compute time is coming from??

To answer my own question for others

To answer my own question for others: - yes, a Worker requesting a socket response from a DO must follow the same protocol as an end client/original request, including a GET method, and "upgrade" header. Omit either of those, and you'll throw/crash. - itty-durable is being modified (transparently) to handle all that in a seamless manner....

When you initially create it yes but

When you initially create it, yes, but after that, the alarm handler can call itself

Weird question Is it possible to run

Weird question: Is it possible to run arbitrary external code from within a durable object? Like if wanted to give users their own durable objects and expose an interface for their to iterate over rows and run JS over them, but not let them write, delete, etc.

pretty sure calling it with 128 keys

pretty sure calling it with 128 keys multiple times over will still be single transaction as long as you dont await, otherwise its probably not possible

I was hoping for some updates to Durable

I was hoping for some updates to Durable Objects announced this week. Have all the announcements been posted now? Is there anything for DOs that I missed?