Uncatchable Exception when response stream is closed about deno HOT 5 CLOSED

Ok, I was able to track down and fix this uncaught exception within my own codebase (/x/observability). I confused it as uncatchable since it seems to be a string instead of an Error and thus has no stacktrace. Since my code is to instrument HTTP serving, I can now attach this exception to the request span and keep the overall server alive. Thank you two for the context!

from deno.

I looked at this again. The exception is coming from the doing things with the writer. I think the locking needs to be tighter. The following handles the exception.

const handler = (_request: Request): Response => {
  const stream = new TextEncoderStream();

  setInterval(() => {
    const writer = stream.writable.getWriter();
    writer.write("data\n").catch((e) => {
      console.log("Error: ", e);
    }).finally(() => {
      writer.releaseLock();
    });
  }, 1000);

  return new Response(stream.readable, {
    status: 200,
  });
};

console.log(`HTTP server running. Access it at: http://localhost:8080/`);
Deno.serve({ port: 8000 }, handler);

This solution doesn't stop the interval, but I'll leave that as an exercise for the reader :).

from deno.

I'm seeing this uncatchable exception in other codebases. Am I correct in understanding that the program will crash if a client walks away while there is a writer locked onto the response stream?

from deno.

If you're using a TransformStream as shown here, you definitely need to catch the write exceptions as those are how the close signal is propagated back through the chain.

We should definitely improve this error message to help point to the source of the error, however.

Note that locking and unlocking the stream is a bit unnecessary -- you should be able to just get the writer once and keep writing to it.

from deno.

IIRC I didn't realize that the write was returning a promise, and at first I just wrapped it in a try / catch without an await. This seems to be a source of frustration for more than a few people, especially if you don't actually need the result of the call, then it's very easy to forget the await.

@mmastrac is right, you don't need to lock and unlock continually, although if others need the writer than you may need to do this. This isn't best design, but the point was that it appeared to be uncatchable, but in the end it wasn't (which is why I closed this). I have seen other cases of uncatchable exceptions though (mostly around web sockets) but that was 2+ years ago and I think they have been resolved now.

from deno.