I've seen customers do much higher than that - when you say plateau at around a hundred, what are you seeing? Feel free to DM me a DO id to take a look

are you thinking of this https://github.com/cloudflare/workerd/pull/449/files#diff-4801bd448b3ceead290776b1dbf2469a0a860ed064e81f2e07f01c26535deaf1R201 for the new API, or something else

ah ok thanks - is that 1024 active connections? i clear ws sockets on error/close, and mark eligible for a new one

yup, that, and now I see it has been increased

that's the new WS hibernation api, not current api

alright, I'm assuming though that the current active limit must be lower than the upcoming hibernated maximum?

there's not an explicit current active limit that I'm aware of, but obviously at some point you're going to run into memory / throughput issues

Interesting that connection limit seems really high even when sending 0 messages in the past I barely got to around like 1000 sockets before it started restarting the DO over and over. Does hibernation mean that we will be able to attach more sockets because its not in memory on the DO? 🤔

I think so, judging by the code it's terminated before the DO and the DO is only spun back up when there is a message coming in

Is this the correct way to use itty-durable in typescript?

typescript
export class Counter extends createDurable({ autoReturn: true }) {
  counter: number;
  constructor(state: {} | undefined, env: {} | undefined) {
    super(state, env)

    // anything defined here is only used for initialization (if not loaded from storage)
    this.counter = 0
  }

  // Because this function does not return anything, it will return the entire contents
  // Example: { counter: 1 }
  increment() {
    this.counter++
  }

  // Any explicit return will honored, despite the autoReturn flag.
  // Note that any serializable params can passed through from the Worker without issue.
  add(a: number, b: number) {
    return a + b
  }
}

@sathoro How did you test DOs locally?

I just tested 10,000 open websockets on the current ws.accept() based api for a DO that's doing nothing other than relaying messages. Obviously I can't claim that will be ok for all workloads, but if you were seeing restarts it probably wasn't strictly due to the number of websocket connections.

Hmm interesting this was a while ago so maybe there have been a lot of improvements

@sathoro I realized we can make a

customStorageAdapter

for supabase that uses D1 😄

now I just need to figure out how to properly get started with D1 lol

ah thanks - and did the DO instance live indefinitely without restarting? clients have built in retry logic per usual with any ws system, but in general for a republisher instance like this it would be great to have the mental model of a piece of reliable infrastructure that can hang around for a long time, providing it is careful not to do too much other than republishing

we don't call Supabase that much from Workers actually, only in a few places right now. the JS SDK works well for that

we're using the JS SDK in our workers too 🙂

was just thinking on how to avoid making extra round trips

for our use case we are able to keep them separate so that we are not calling it too much. actually we were only using it for the JWT (which is cached) and only added an insert operation this week which is called from a queue

right, I was thinking it'd be easier to use custom storage (which would use DOs) for that 🙂

It didn't restart during the time I was testing with it. As far as reliable goes, connections aren't going to last a week in any case, so you'd need clients to reconnect when restarts do happen.

exactly - i'll put some DO instantiation events to observe today (this is for the publisher backend behind firesky.tv https://discord.com/channels/595317990191398933/783765338692386886/1103429433588731904)

how long can a Durable Object run when called from an alarm? I see CPU time is 30 seconds but is there a limit for the total runtime?

I got one to run for over 20 minutes but then I hit this limit:

Error: Subrequest depth limit exceeded. This request recursed through Workers too many times. This can happen e.g. if you have a Worker or Durable Object that calls other Workers or objects recursively.

There isnt really a limit for runtime. Subrequest depth limit is an interesting one and sounds like you have accidental recursion going on that shouldnt be there.

oh thank goodness, I wish I knew that earlier before I tried switching to CF Queues 🤣

okay this is a weird one, we are still getting errors like this

Durable Object reset because its code was updated.

When you redeploy the worker it kills off the old DOs and resets them

but I patched itty-durable and thought I fixed these. can somebody please check to see if something is wrong with my retry logic: