Disconnecting client from server-side too quickly leaves client alive #5088
Comments
|
Not sure if it's the same issue but I found something similar while updating tests in Primus. Here is a test case: const eio = require('engine.io');
const eioc = require('engine.io-client');
const http = require('http');
const httpServer = http.createServer();
const eioServer = new eio.Server();
httpServer.on('request', (req, res) => {
eioServer.handleRequest(req, res);
});
let socket;
eioServer.on('connection', () => {
socket.close();
httpServer.close();
});
httpServer.listen(3000, () => {
socket = new eioc('http://localhost:3000/');
});The process does not exit. Here is what happens:
|
|
Any updates on this issue? |
|
I've run into the same issue with Cordova and its implementation of listeners errors at: https://github.com/socketio/engine.io-client/blob/main/lib/socket.ts#L915 I assume this is because the If not the code beneath to mark the connection as closed doesn't run and an error is thrown while removing the this.offlineEventListener. The traceback goes all the way down to FYI - If you're building this on an M1 Mac (darwinarm64), I needed to override the version of ngrok used by zuul-ngrok in the package.json i.e: "overrides": { Ngrok 4 supports M1 Mac, but the zuul-ngrok hasn't been updated for 6 years. |
darrachequesne
added
the
package:engine.io-client
In some specific cases, the transport was not closed right away,
leaving the Node.js process alive even after closing the server.
The HTTP long-polling transport would be closed after the heartbeat
failure and the `closeTimeout` delay (20 + 25 + 30 seconds).
Example:
```js
io.on("connection", (socket) => {
// the writeBuffer is not empty, so the transport is not closed right away
io.close();
});
```
Related: #5088
Note: for support questions, please use one of these channels: stackoverflow or slack
You want to:
Current behaviour
Using socket.io, but this looks to be an underlying bug in engine.io. The server successfully closes the connection, but the client endlessly polls for a connection if done too quickly after the connection has been established.
Steps to reproduce (if the current behaviour is a bug)
I am doing the following in my test:
socket.disconnect(true)). Then the server closes itself.Setting the transport to websocket-only solves the issue for me.
Expected behaviour
The client should shut itself down when the server tells it to disconnect.
Setup
3.2.1Other information (e.g. stacktraces, related issues, suggestions how to fix)
My best guess is that some kind of race condition is occurring between the server-initiated shutdown and the client's transport upgrade from polling to websockets, leaving the client in an inconsistent state.
The debug logs are illuminating:
The text was updated successfully, but these errors were encountered: