https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • u
    Oh this is actually inside the Durable Object code so thats even more of an issue...
  • s
    so might not be able to build it into itty-durable then? 😦
  • u
    That error will never be solvable from inside the DO. You would need to recreate the stub that fetches the DO so you can connect to the new machine the object is on.
  • s
    or maybe have to do in a different place
  • s
    maybe I need to do the retrying in this:
  • d
    Is there a good guide for getting started on local dev with DOs?
  • s
    I use wrangler with 
    --local --persist
    and it "just works"
  • g
    Has anyone had trouble with differences in how WebSocket clients work when running locally with 
    wrangler dev --local
    vs plain 
    wrangler dev
    or when deployed? I am building a WebSocket client for Discord's Gateway API using DOs. Everything works when running locally with 
    --local
    , but when I remove 
    --local
    or when I deploy to CF, my WebSocket client (created via 
    new WebSocket()
    ) immediately gets an 
    error
    event that says 
    Failed to establish the WebSocket connection: expected server to reply with HTTP status code 101 (switching protocols), but received 401 instead.
    . Discord's Gateway WS protocol doesn't require any authorization to open the WS connection normally (a token gets passed in a message later), and this exact same code works with 
    wrangler dev --local
    .
  • v
    hey guys, just want to be sure of one thing. Each DO will never process two requests in parallel? Or it still can process them in parallel? In the documentation it says it is single-threaded, but that does not mean they can't be processed in parallel using a event loop. Doing some local tests with miniflare I see that the second request only start after the first one ended. But I am not sure if that is a mismatch on Miniflare or if it actually works like this.
  • h
    It can, though you can use 
    blockConcurrencyWhile
    to prevent the DO from receiving any further events
  • c
    There can be multiple concurrent requests on the same DO, but only one of them will be doing work on the event loop at any given time. IE there is no parallelism for a single DO. In your local tests with miniflare was the first request doing anything that would yield the event loop, e.g. await on IO?
  • v
    I did use a 
    await sleep(10000)
    to test. sleep here being a promise over a setTimeout right, so no parallelism, but I still can have concurrency right? Sry I used the wrong term.
  • v
    I expected both requests to execute concurrently. But the second one only started after the first one finished.
  • v
    to be sure I am using 
    blockConcurrencyWhile
    that @HardAtWork suggested. But I guess that is a bug in miniflare (?)
  • s
    @Vinicius Zaramella > I expected both requests to execute concurrently > to be sure I am using blockConcurrencyWhile pick one...
  • j
    whoa, durable objects event going on?
  • j
    errors spiking starting at about 4.35pm central
  • u
    things seem to be fine on my end... what errors?
  • d
    seeing a few errors, nothing noticeably higher than normal here either
  • j
    Error: internal error
  • j
    Error: Cannot resolve Durable Object due to transient issue on remote node.
  • u
    I do have a few internal errors only from MFE/MEX
  • d
    any particular colo/region having issues?
  • u
    dont have any of the transient issue on remote node errors myself
  • j
    DFW - error inside DO in question: 
    Error: Internal error in Durable Object storage write caused object to be reset.
  • j
    I guess I have an unlucky remote node
  • j
    51571a93b143b2d4d0836f765381b5c3f3f29bca9035a063925d4ce861fd5248
    is the DO id if any cf folks are around
  • d
    last time I got a transient error was 30th April :/
  • j
    how transient was it?
  • d
    the specific error message
1...549550551...567Latest