That sounds correct, yes. In fact,

put()

operations will almost always complete immediately. The promise returned by

put()

only exists to apply backpressure -- if you write too much stuff without taking a break, you risk exceeding your memory limit, in which case

put()

will start returning promises that pause for a bit. This promise actually will never indicate a failure (absent a bug in the runtime); instead, a failure resets the object before it has a chance to communicate with the rest of the world. So, any app which doesn't do excessive writes all at once can probably ignore the promise returned by

put()

entirely.

Anyone know about what rps you can get with WebSockets in DOs?

The docs for the newish sync() method on the transactional storage API says: > Synchronizes any pending writes to disk. But I am guessing actual behavior is that they are also replicated -- that is, this this promise doesn't resolve until the writes are durably stored in multiple locations. Can anyone confirm this?

We have measured 8k/s 4kb messages outbound if DO is doing nothing else. Rate isn’t significantly affected by making messages smaller. It appears to be a per-write overhead, not per byte, probably because of the cost of underlying syscall.

Have not measured inbound

Long time no post. 🙂 Can I call a Durable Object from another Durable Object? Having a hard time doing so using

itty-router

.

Yes you can. We do this in our project.

Yes, you should just be able to create a stub and use fetch just as you would from a regular worker.

Cool, thanks. Must be an

itty-router

problem then. My environment in the entry Worker can find my DO stub, my environment within the DO cannot find the stub of the second DO.

Are you using itty-router inside the 1st DO?

Yeah

I'm not doing that, just itty in the main worker (entry point for the app).

js
.post('/close', withParams, withContent, async (
      request, env
    ) => {
        const userId = env.User.idFromName(`user`);
        const user = env.User.get(userId);

Cannot read properties of undefined (reading 'User')

Inside the DO, I get the env object from the constructor like this.

constructor(state, env) {
            this.state = state
            this.env = env

Will try now.

Worked a charm. 🙂

Love this community, thanks a ton @aranchelk. Looks like the

itty-router

per-request environment variable does not carry the DO stubs within a DO but it does in the constructor. The per-request environment variable in a Worker does have the stubs.

You're welcome, no worries at all.

I just ran into this error. It doesn't seem to be documented anywhere in the docs and kinda breaks my use case. > Maximum number of keys modified in a transaction is 128. 😦

Curious, what constraint leads to this limit? Maybe something to do with the maximum size of updates when they're replicated to a 2nd fault domain? For my workload, I'm fine with loosing some writes as long as things are consistent (the entire transaction is either comitted or lost). It seems like it should be physically possible to remove this limit for transactions with allowUnconfirmed=true.

Can the runtime collapse a WebSocket connection? As in, if a requests passes through three different Durable Objects, and then is returned with a WebSocket, is the WebSocket threaded through all three of those objects, or only from the client to the last object?

Yielding to the

fetch()

handler

And also I want to make sure all writes are coalesced, so I guess I can just await the last one?

try

new Date()

I always use

new Date().getTime()

If that works, something is really borked, because this ```js new Date().getTime() === Date.now() ```should always be

true

...

lol idk, the docs say within a few ms but maybe the time you get is not real???

It's always at least a few ms. behind, since the Timer is frozen

for visibility/observability only, cloudflare analytics engine is really nice for this

yes unfortunately it's a hard limit - agree that maybe putting that somewhere in the docs would be nice, it's only mentioned for individual calls, and like you said - it's a brick wall the first time you run into it in production