https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • t
    in all 3 connections, a publisher, a subscriber and this debug listener
  • t
    but i dont get anything there either
  • t
    its so strange
  • t
  • k
    FWIW, not sure if this is your issue, but we have a known issue right now where when you update your code, any open WebSockets don't get proactively disconnected -- instead they remain connected to the old version of the object, while a whole new version of the object runs using the new version of the code. So you get "split brain". Anyone who connected before the update won't see anyone who connected after, and vice versa. We intend to fix that by force-disconnecting all WebSockets on a code update, so that they have to reconnect to the new version.
  • k
    So after you push a new version of the code, for now, you need to manually restart all your clients...
  • t
    I became aware of that while debugging and uploading new instances. I'm pretty sure its not that i waited a bit and send some tests "echos" to make sure that im on the new one, also making sure it sends the right message back. In this iteration the keyword was listen but in the previous iterations it was debug. So i check to make sure all clients are connected to the right server and the right code is also on there
  • t
    ive spent alot of time debugging this as you can see haha im at it for 3 days now and starting to get a bit desparate
  • k
    If you can narrow it down to a minimal self-contained script that demonstrates the problem, with complete instructions for reproducing, we might be able to take a look to see if there's anything wrong in our implementation. But I think most likely this is a case of debugging being really hard right now... we need to improve the tooling.
  • t
    I will do this Kenton, really keen to get this sorted. Give me a couple of hours
  • j
    @User, love the feedback. i had similar questions.
  • j
    awesome to see 
    waitUntil
    make it to DO... @User, can you clarify whether this is a method or a function? ie, does it need to be bound to the 
    state
    object? https://discord.com/channels/595317990191398933/802187271067140107/807309699544121384
  • g
  • g
    state.waitUntil(promise: Promise)
  • j
    sure, but what i'm asking is whether i can use something like 
    this.waitUntil = state.waitUntil
    or whether the function is indeed a method that needs to be bound to its object.
  • j
    also, is there no way to 
    waitUntil
    for the "parent" worker of a DO?
  • g
    Gotcha. Not sure. My guess is that would work, and it should be easy enough to test out! I was wrong. You cannot. You have to call it from 
    state.waitUntil(...)
    . Seemingly nothing stopping you from saving 
    this.state = state
    and then just calling 
    this.state.waitUntil
    though 🙂
  • e
    any DO router out there? 🙊
  • g
    I think you might be a bit early to the game. I've just been re-using my normal router, and it's working well enough.
  • e
    Mind sharing your router with me? I did some routing but cannot say I like it 😄 However it works, so I am happy
  • g
    Oh, mine is super gross at the moment too. When I was prototyping the other day, I was just using this for both the Worker and the DO:
    Copy code
    typescript
export class Route {
  constructor(method, pathRegex) {
    this.method = method.toLowerCase();
    this.pathRegex = pathRegex;
  }

  matches(request) {
    if (request.method.toLowerCase() !== this.method) return false;
    const url = new URL(request.url);
    if (!url.pathname.match(this.pathRegex)) return false;
    // I'm re-reading this now, and I can only apologize.
    return true;
  }
}

export class Router {
  constructor() {
    this.routes = [];
  }

  handle(request, ...args) {
    const route = this.routes.find(([route, handler]) =>
      route.matches(request)
    );
    if (route) return route[1](request, ...args);

    return new Response(null, { status: 404 });
  }
}
    I got that wrangler branch working though, so it should be more than possible to pull in any router you like (e.g. https://github.com/glenstack/glenstack/tree/master/packages/cf-workers-router)
  • e
    This one looks much better than mine, thanks!
  • k
    It's a method. Note that it specifically forces the Durable Object to stay alive (not just the containing isolate, which may host multiple objects). And no, there's still no way to do 
    waitUntil()
    in a regular (non-DO) worker that uses modules syntax; we're still figuring out where we want to stick that in. Probably a third parameter to the fetch handler...
  • j
    this API may be too cute, but you could obviate the need for another parameter by letting the fetch method take an async generator, a la: https://twitter.com/jedschmidt/status/1305313776409870337?s=20
  • g
    Oh that is beautiful ❤️
  • g
    I love that
  • j
    i like it too, i do this for almost all my workers.
  • j
    it's basically the reason async iterators exist too.
  • g
    Does TypeScript handle it okay? A quick look at the docs says it should?
  • j
    ie, decouple returning from processing
1...111213...567Latest