Crash on Deno Deploy: Connection reset by peer

[erfanium]

ConnectionReset: Connection reset by peer (os error 104)     
at async read (deno:ext/net/01_net.js:21:19)     
at async BufReader.read (https://deno.land/[email protected]/io/buffer.ts:314:18)     
at async BufReader.readFull (https://deno.land/[email protected]/io/buffer.ts:343:28)     
at async WireProtocol.receive (https://deno.land/x/[email protected]/src/protocol/protocol.ts:77:34)

[jtoppine]

Same error in Deno 1.20.3, mongo 0.30.0 (not deploy, regular Ubuntu server, mongodb 5.0.6 running locally on the same PC)

error: Uncaught (in promise) ConnectionReset: Connection reset by peer (os error 104)
      rr = await this.#rd.read(this.#buf);
           ^
    at async read (deno:ext/net/01_net.js:24:19)
    at async BufReader.read (https://deno.land/[email protected]/io/buffer.ts:383:12)
    at async BufReader.readFull (https://deno.land/[email protected]/io/buffer.ts:415:20)
    at async WireProtocol.receive (https://deno.land/x/[email protected]/src/protocol/protocol.ts:110:28)

Maybe automatic reconnect could handle these situations, if we ever get those? #278

[FinlayDaG33k]

Same here on Docker (using the denoland/deno:ubuntu-1.24.0 image and the Mongo 5.0.6 docker image on the same host.

error: Uncaught (in promise) ConnectionReset: Connection reset by peer (os error 104)
      rr = await this.#rd.read(this.#buf);
           ^
    at async read (deno:ext/net/01_net.js:28:19)
    at async BufReader.read (https://deno.land/[email protected]/io/buffer.ts:383:12)
    at async BufReader.readFull (https://deno.land/[email protected]/io/buffer.ts:415:20)
    at async WireProtocol.receive (https://deno.land/x/[email protected]/src/protocol/protocol.ts:110:28)
    ```

[FinlayDaG33k]

I did manage to "circumvent" this issue for now by having my app make a small query every 5 seconds (might want to increase this but it'll do for now), keeping the connection alive.
Because I use DangoDB and am not very knowledgeable on MongoDB, this was the easiest way for me to accomplish it for me.
A better solution will need to be built.

I don't know how this will affect users of Deno Deploy since I am not familiar with the service.

EDIT: Here's a little overview on when my app crashed (red section) vs after the "fix" (green section).
Missing dots on the graph represent moments when the app crashed.
As one can see, the crashing was pretty frequently before the fix and after it, it hasn't crashed a single time yet.

Update after ~8 days

It's been about 8-days now since I've added this and I haven't had a single crash yet.
So it does seem that implementing some kind of keepalive may help solve this issue.

[jespertheend]

While developing locally I'm connecting to a remote mongo instance, and I am getting this when I close my laptop lid for a while.
For the time being my workaround is this

globalThis.addEventListener("unhandledrejection", e => {
	const err = e.reason;
	if (err instanceof Deno.errors.ConnectionReset || err instanceof Deno.errors.BrokenPipe) {
		if (err.stack?.includes("https://deno.land/x/mongo")) {
			console.warn("Database connection has been lost, restart the dev script in order to reconnect the database.");
			e.preventDefault();
		}
	}
});

The database connection stays broken but at least my development script doesn't crash.

[manyuanrong]

This is indeed a problem with keepalive, which also exists in other database drivers of deno. I have recently used redis and pgsql in a production environment. Sending heartbeat requests regularly is simple and effective. Of course, this should also be added as a feature of the driver library.