if you're using the DO as a source of truth rather than just coordinating writes, keep in mind what happens if DO storage write succeeds and KV write fails

i.e. is it bad for your use case if they're out of sync for an extended time, are you ok with setting a DO alarm to retry KV writes

Thank you, very helpful!

Any docs I could look at to go deeper on both KV write failure modes (curious if they can fail outside of a write operation or if I need to just write my own transaction-like behavior), and/or DO alarms?

as far as alarms go, besides the existing docs there's the announcement blog post with an example at https://blog.cloudflare.com/durable-objects-alarms/

KV wise, I'm not the KV manager any more so you may be better off asking in the KV specific channel; my main point wasn't so much about esoteric failure modes but the obvious one of DO writes works and KV write doesn't for whatever reason. As long as you give your alarm handler a way to tell that a given DO value hasn't been successfully written to KV so it can retry, should be ok

Appreciate it, this seems like enough to get me started! Thanks again.

I had assumed that while the value of the KV may or may not be in cache, the key and metadata were kept in some sort of in-memory index. Are the keys in memory but not the metadata? Or are neither of them likely in memory?

IIRC, either everything is in Cache, or nothing is.

playing with the new tcp beta which i can use for postgres.. Can/Should connection pools go to a durable object? and how would that work

ts
import { Pool } from 'pg'
import { DB } from './kysley-db'
import { Kysely, PostgresDialect } from 'kysely';

const db = new Kysely<DB>({
    dialect: new PostgresDialect({
      pool: new Pool({
        connectionString: "the_url",
      }),
    }),
  });

tho i wonder if the entire thing should be a DO

is there something you read that led you to assume that?

With all the upcoming changes to pages, I wonder if being able to deploy DOs from a pages deployment is in the roadmap? It’s not a huge issue to deploy them as normal workers but it would be nice to unify it

Just asked this for you in the Dev Week Pages call - It is on the roadmap, yes

Thanks for asking! That’s awesome, it’ll be a very nice feature to reduce complexity

Hello Beautiful Cloudflarians, I am having an issue where my durable object is setting up a web socket connection. This works as expected in my local dev environment but not when I deploy it. I am a bit lost about the next steps to take to try to fix the issue. Has anyone run into such a problem before or knows how I can track down the bug?

👋 Hi, could you share your DO code with us?

have you tried deploying the websocket example at https://github.com/cloudflare/workers-chat-demo

I will take a look at that repo and go through all the code tomorrow. I am using hono btw.

Typical... spent 5 hours trying to solve a problem on my own, ask for help and then spot the problem I was having. lol.

Thanks for the replies though.

Quack

I once spent three days trying to debug an issue, turns out I had managed to fix the issue within 10 minutes of starting to investigate. The remining 3 days were due to a new bug that was introduced by the debuging....

Yep, thats exactly why I just went into all open files doing a loooooong ctrl-z

removing lots of console.log("WTF!")

"Assumed" is probably too strong. Maybe "guessed". I didn't read anything that says otherwise and I know it says that it's not memcache but it just has so many similarities to things like memcache. Also, databases try to keep their indexes in memory. I think of the key as the field that is always indexed. Because metadata came back with list() operations, I guessed it was probably with the keys and only the values required disk round trips. I take your response to mean, that's not the case.

it seems like smart placement doesn't work with durable objects

i have the following scheme: database <- durable object <- worker with smart placement

i kinda want all of the things to be close to database but worker (with smart placement) always displays insufficient requests

is there a way to make it work?