https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • b
    We need to make the "limits" page more clear for DOs
  • v
    So I did test that ... and yes, sometimes no close frame is being sent, making the client socket "hang". Other times the client socket is closed immediately (1006). Even with the same DO instance, some clients do receive the close, others don't. Is there a recommended way to detect this situation in the client ASAP? I assume the worker connecting to the DO is terminated the same way, so it can't do anything. Or do I need to handle that with my usual logic for broken TCP connections? Which would be unfortunate since we usually only start that after many seconds of silence from the server ...
  • z
    Using the module system, is it possible to access the event object somehow?
  • z
    export default { async fetch(request, env) { return await handleRequest(request, env); } }
  • z
    for example using event.waitUntil
  • v
  • z
    Ah great thanks
  • w
    Thank you very much for your reply. So how exactly does a websocket stay open longer than the maximum duration of a worker?
  • v
    AFAIK the maximum duration for DOs is extended with every message going in or out of the websocket.
  • v
    ... so it can not stay in memory doing nothing, but as long as it does something productive every once in a while, it may stay.
  • w
    I see. Thank you for the clarification.
  • z
    Vanessa, Inside the Durable Object class, inside the fetch method, if I run an async function there without using await it should continue in the background? because mine does not seem to execute without using await
  • z
    I wrote a quick example:
  • z
    Copy code
    export class DurableObject {
  constructor(state, env) {
    this.state = state;
  }
  async timeConsumingFunction(url) {
    const ref = 'ref-of-storage'
    const resp = await fetch(url)
    const data = await resp.json()
    await this.state.storage.put(ref, JSON.stringify(data))
  }
  async fetch(request) {
    const ref = request.url

    let stored = await this.state.storage.get(ref);
    let currentPageviews = stored || 0;

    currentPageviews++
    await this.state.storage.put(ref, currentPageviews);

    this.timeConsumingFunction('slowapicall.com?url=' + ref) // in background aka event.waitUntil
    
    return new Response(currentPageviews)
  }

}
  • z
    timeConsumingFunction only works for me when I await it
  • m
    The runtime doesn't send a close frame -- it hard-disconnects the websocket. Our reasoning for this behavior is we can't always guarantee we'd be able to send a close frame when a durable object instance is shutdown. My guess to the behavior your experiencing on the client side is, the sockets that are hanging aren't actually being used -- once you try to send something, that send should fail, and trigger the 1006 close event (which indicates a hard disconnect)
  • v
    Not quite ... the browser doesn't know the socket is closed yet. Sends appear to succeed, it's just that the 
    socket.bufferedAmount()
    goes up and up and only after a minute or so do I get the 1006. I know the close frame is unreliable, just like the TCP connection can be interrupted at any time. That is unavoidable - just like arbitrary delays in packets arriving. Our websocket client code handles that. But. If the server can manage to send a close frame, then it really should, because that informs the client immediately that it should reconnect. We can easily smooth over a 1 second connection loss, but we cannot just reconnect every time there is a 1 second delay in the connection. I guess you are sending a FIN packet though because sometimes the websocket does close immediately? Although the full websocket closing handshake would be even nicer. Or, alternatively, some other way to smoothly handle code updates. Our existing system dispatches new sessions to updated instances, but keeps old instances alive until the last connection drops. I can see why you would not want to implement that, but we'd need something.
  • v
    @User you need to keep a ping going
  • v
    no pong == remote end is dead, even if your OS thinks the TCP socket is open
  • v
    Yes, I'm pinging every 30 seconds.
  • v
    i think its due to the way cloudlfare shuts down the DOs in a dirty way
  • v
    without properly closing the socket
  • v
    so the TCP stack the DO is running on doesnt get to properly close it
  • v
    ah i see, yea it wont be reliable to depend on this tho
  • v
    you can ping every 5 sec for more realtime things
  • v
    i really think they should support a ping at the protocol level that will be free
  • v
    and wont bite into CPU time
  • s
    Is there a maximum size per instance of a durable object class?
  • j
    question: how would you approach implementing the equivalent of Slack's 
    /remind
    feature using Durable Objects? ie, letting users enter -- in their own timezone -- multiple arbitrary recurring times at which tasks are run. for example, reminding a user in 
    America/New_York
    to eat lunch daily at 13:00.
  • j
    specifically: 1. what's an easy way to get a list of tasks that need to be run for any given minute, keeping in mind that 13:00 in New York is different in UTC depending on DST? ie, run a cron every minute that for all tasks converts UTC to task timezone, and filters on matches? or run a cron daily that pre-computes all tasks into UTC and store in DO/KV? 2. how would you handle situations where more than 50 tasks need to be executed at a given time, exceeding the worker subrequest limit?
1...99100101...567Latest