Does not reconnect when disconnect isn't clean

[realtux]

Describe the bug
Reconnection works great when the connection is severed cleanly, such as when a client is disconnected remotely. However, when doing something like pulling an ethernet cable or disconnecting from wifi, the client will just hang forever. I've seen this issue on similar tools, where the issue is the keepalive mechanism is either not performing correctly or is configured incorrectly.

Logs
No logs, client hangs and outputs nothing until manually restarted.

Environment
Xubuntu, Node.js 18, latest xmpp.js.

[realtux]

Updated information:
Only doesn't reconnect when using xmpps:// schema on port 5223. xmpp:// on 5222 works fine.

[raucao]

I just stumbled upon the same issue.

After I couldn't find an easy fix, I started implementing pings in my program, but halfway through I thought it was a bit silly patching over this from the outside, when a stated goal of the library is not having to manage connections manually. I think it should be treated as a bug, because loosing connectivity for any reason whatsoever should eventually result in an automatic reconnect.

[sonnyp]

A reproducer would be useful.

[raucao]

You can just disconnect your Internet (e.g. turn off wifi) while any program using the latest npm module is running.

The simplest example would probably be the official example code in the client README, which should at least log that you're back online after a reconnect.

[realtux]

external ping is how i ultimately solved this, but it doesn't feel like something that a user should have to do, since reconnect logic does exist already, just not for the xmpps scheme. i spent some time looking at the code base to propose a fix, but i'm just not familiar with it so i had a hard time locating where the tcp logic is. i'll continue to investigate.

[ilya-lopukhin]

the library is very buggy currently without the connection present. The getaddrinfo ENOTFOUND internal xmppjs error (at GetAddrInfoReqWrap.onlookup) is skipping the proper on('error') handler, propagating to the bottommost unhandledrejection handler and crashing the whole node process around it in case the connection ended abruptly