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

Ahh sorry, here's how my login flow is working.

+---------------------+
                    |  Login Flow         |
                    +---------------------+
                             |
                             |
                   +---------v----------+
                   | AuthC1App DO       |
                   | get application    |
                   | details            |
                   +---------+----------+
                             |
                             |
                             |
                   +---------v----------+
                   | AuthC1User DO      |
                   | get user           |
                   | details            |
                   +---------+----------+
                             |
                             |
                             |
                   +---------v----------+
                   | KV                 |
                   | get salt           |
                   | using user ID      |
                   +---------+----------+
                             |
                             |
                   +---------v----------+
                   | AuthC1User DO      |
                   | create session     |
                   |                    |
                   +---------+----------+
                             |
                             |
                   +---------v----------+
                   | AuthC1Token DO     |
                   | create access      |
                   | and refresh token  |
                   +---------------------+
                             |
                             |
                             |
                   +---------v----------+
                   |         Response    |
                   |    return tokens    |
                   +---------------------+

This is more of a review or suggestion ask. I was under the impression that as all of the DO calls will happen in the worker itself, so the whole flow's resoponse time under ~200ms but right now the whole login API call takes around 1.5s.

How do Workers Trace Events logs work when it comes to durable objects?

Hey all, I have a system set up with Durable Objects which consists of a two layer network, where clients establish websocket connections with one of the N top level Shards and can send websocket messages to it. I then have a root level DO, which fetches run time properties from each of the N top level Node in a 1 second interval, samples / parses the data, then sends it back via to all N top level nodes, which are propogated back to all connected connected users via websocket messages. This worked great locally using miniflare. However, once deployed, I'm finding that the connections at some level just "die". All the user -> top level node websocket connections all appear to be fine and not closed, when inspecting the network. However, for some which is very challenging to diagnose, they stop receiving any websocket messages after some period of being connected (which seems to be anywhere between 10 seconds and 10 minutes). I'm suspecting something the root durable object instance is just dying, causing the connections between N shard -> root to close, however it was my understanding that these instances should keep running as long as they are being used, and that the root having an alive websocket connection and repeatedly fetching from the top level instances would keep it alive? I understand my message I've just written is lengthy, however I'm hoping that someone here will notice my plea and help me understand what could be the cause of the DO dying.

Does the durable objects list endpoint return in lexicographic order the same as the KV list endpoint?

Not mentioned in the API docs

I believe it does, at least according to behaviour I've seen, and quoting from the docs >

reverse: boolean

> If true, return results in descending order instead of the default ascending order. > Note that enabling this does not change the meaning of start, startKey, or endKey. start still defines the smallest key in lexicographic order that can be returned (inclusive), effectively serving as the endpoint for a reverse-order list. end still defines the largest key in lexicographic order that the list should consider (exclusive), effectively serving as the starting point for a reverse-order list.

Ahhh.. but the IDs are derived from the names so I guess not useful

Unless the IDs have the creation time at the beginning?

Ah are you referring to https://developers.cloudflare.com/api/operations/durable-objects-namespace-list-objects ?

Yep

Where did your quote come from?

I don't think there are any guarantees around the ordering there

That's for the storage list operation

Was just hoping to be able to query recent objects without having to store Extra references somewhere

Is there any reason I couldn't run a website in a durable object?

Would there be big performance issues?

The biggest limitation is the limit of ~100 RPS

Oh nice, that's plenty enough for me

I guess you also need to make sure not to block the gates?

I mean, is there a particular reason you want to run it from a DO?

You'll only have it in one location, as opposed to something like Pages, or a Worker site, which would run everywhere

For me one location is better, all requests are going to be from the same place

And it means I can use kv without cache staleness issues

Then I don't see any particular problem with that

I was going to say, if you chose to do that, it'd probably be better to use KV than DO storage, because of the size per key restrictions (128kb/key)

Do you know of a nice DO based rate limiting example? I feel like there might have been a blog post..

I guess it's not really a DO thing as it doesn't even need persistence

just need a good in-memory rate limiter implementation