idleTimeout not working in WebSocket

[ElYaiko]

What version of Bun is running?

0.2.1

What platform is your computer?

Darwin 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:35 PDT 2022;

What steps can reproduce the bug?

When I add the property idleTimeout to 8 for example, the connection keeps connected after not sending a message in more than 8 seconds.

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

The server to close the connection after not sending a message in the timeout.

What do you see instead?

The connection keeps connected.

Additional information

No response

[betamos]

Is a bump inappropriate here?

• This reproduces consistently on 0.5.8, just set idleTimeout: 8 on a minimal ws handler and connect from a local client.
• The default is 120 but even waiting for > 240s results in neither a server-sent ping nor a disconnect.
• Using Node + uWebSocket with the analogous config (and sendPingsAutomatically: true) works like a charm. The server keeps the connection alive automatically while discarding stale clients.

I tried to trace the call chain to see if anything was missing in piping the params to uws. Bun seems to set both sendPingsAutomatically (although this is not exposed in the Bun APIs) and idleTimeout which should work. For instance, setting idleTimeout: 7 causes a C++ error in uws, which is expected. Unfortunately, I don't know Zig and wasn't able to dig in further.

The reason this is important in my view is:

• It greatly simplifies for WS based applications to utilize the uws native heartbeats, and thus disconnect stale clients (who don't send a TCP FIN). This is used for online status in chat etc, at a very low overhead cost.
• Many OSs seem to leave non-closed TCP connections to linger for very long times, which can occupy resources associated with the conn.

Let me know if I can help.

[Jarred-Sumner]

I suspect this is related to HTTP Keep-Alive

[betamos]

HTTP Connection: keep-alive is not present with Websockets. TCP keep-alives should not make a difference either, since the timescales we're talking about are so small (10s-120s) that they're not reliable for detecting dead peers ~quickly.

In either case, uWebSockets should handle the full socket lifecycle in Bun, no? Since it's the same library, but different behavior, I'm thinking that something got messed up with the Zig -> C++ wiring. I just couldn't find what, everything looks good.

[sheryy]

Can someone please let me know If there is any plan to fix this bug soon? I cannot used Elysia (Bun based Web Framework) because of this issue.

If there is no plan to fix this issue then I will have no choice but to pick NodeJS v2.0, Fastify and uwebsocket.js to implement a real time communication module for my company.

[Lan-Hekary]

I am using bun v1.0.4 now and still the issue persists. seems like the properties sendPings and idleTimeout does not affect the behavior at all.