Socket.io: JS exceptions thrown while just idling (WebSocket is already in CLOSING or CLOSED state.)

Experiencing absolutely the same issue and the code is correct. This only happens in Chrome for me. Mozilla is clean. In chrome, this err is raining over and over and duplicating all the chats I have. I tried using this method
socket.on('disconnect', () =>{ socket.disconnect(); });
It doesn't disconnect the client from the server. Repo in case needed https://github.com/antoniab123456/Chat_app

the same problem here

browser is just idling, then the errors come up.

I used Chrome and mac OS

Yes guys, can someone address that? Perhaps we need another line of code to fix that?

I have the same problem with socket.io and Chrome
Mac OS 10.13.5
Chrome Version 67.0.3396.87 (Official Build) (64-bit)
Node: 10.3.0
Express: 4.16.3
socket.io: 2.1.1

In Firefox everything is fine.

Error details below:

index.js:83 WebSocket is already in CLOSING or CLOSED state.
(anonymous) | @ | index.js:83
  | e.encodePacket | @ | index.js:83
  | (anonymous) | @ | index.js:83
  | r.write | @ | index.js:83
  | r.send | @ | index.js:83
  | r.flush | @ | index.js:83
  | r.sendPacket | @ | index.js:83
  | r.ping | @ | index.js:83
  | (anonymous) | @ | index.js:83
  | setTimeout (async) |   |  
  | r.setPing | @ | index.js:83
  | r.onPacket | @ | index.js:83
  | (anonymous) | @ | index.js:83
  | r.emit | @ | index.js:83
  | r.onPacket | @ | index.js:83
  | r.onData | @ | index.js:83
  | ws.onmessage | @ | index.js:83

When I click on the index.js:83 it takes me to this module:

/**
 * Expose `Backoff`.
 */

module.exports = Backoff;

/**
 * Initialize backoff timer with `opts`.
 *
 * - `min` initial timeout in milliseconds [100]
 * - `max` max timeout [10000]
 * - `jitter` [0]
 * - `factor` [2]
 *
 * @param {Object} opts
 * @api public
 */

function Backoff(opts) {
  opts = opts || {};
  this.ms = opts.min || 100;
  this.max = opts.max || 10000;
  this.factor = opts.factor || 2;
  this.jitter = opts.jitter > 0 && opts.jitter <= 1 ? opts.jitter : 0;
  this.attempts = 0;
}

/**
 * Return the backoff duration.
 *
 * @return {Number}
 * @api public
 */

Backoff.prototype.duration = function(){
  var ms = this.ms * Math.pow(this.factor, this.attempts++);
  if (this.jitter) {
    var rand =  Math.random();
    var deviation = Math.floor(rand * this.jitter * ms);
    ms = (Math.floor(rand * 10) & 1) == 0  ? ms - deviation : ms + deviation;
  }
  return Math.min(ms, this.max) | 0;
};

/**
 * Reset the number of attempts.
 *
 * @api public
 */

Backoff.prototype.reset = function(){
  this.attempts = 0;
};

/**
 * Set the minimum duration
 *
 * @api public
 */

Backoff.prototype.setMin = function(min){
  this.ms = min;
};

/**
 * Set the maximum duration
 *
 * @api public
 */

Backoff.prototype.setMax = function(max){
  this.max = max;
};

/**
 * Set the jitter
 *
 * @api public
 */

Backoff.prototype.setJitter = function(jitter){
  this.jitter = jitter;
};




//////////////////
// WEBPACK FOOTER
// ./~/backo2/index.js
// module id = 41
// module chunks = 0

Line 83 is:

this.jitter = jitter;

I sort of have the same problem, with backo2.js and in line 83. here is my error:
index.js:83 Uncaught TypeError: Failed to execute 'readAsArrayBuffer' on 'FileReader': parameter 1 is not of type 'Blob'.
at n (index.js:83)
at n (index.js:83)
at n (index.js:83)
at n (index.js:83)
at n (index.js:83)
at n (index.js:83)
at Object.e.removeBlobs (index.js:83)
at s (index.js:83)
at r.encode (index.js:83)
at r.packet (index.js:83)
and dont worry about the other stuff, they all are in line 83, which is this.jitter = jitter;
It is annoying me so much as there isnt really any solution in google.

Has anyone found a temporary solution? @antoniab123456 were you able to fix your chat app so that it doesn't duplicate your chats? It's doing the same thing to me.

Setup
OS: Mac OSX
Browser: Chrome 67.0.3396.99 (Official Build) (64-bit)
Node v10.5.0
Socket.io v2.1.1

I am facing the exact problem @getify mentioned in chrome. Has any one found any work around for this?

Same problem. Can someone please respond to this?

Same problem.

Setup
OS: Mac OSX
browser: Chrome 67.0.3396.99 (Official Build) (64-bit), Node 9.6.1
socket.io version: 2.1.1

@19smitgr idk what you mean by 'dulplicate chats' which sounds off topic which could be solved by broadcasting instead if you mean 'duplicate message in same screen'.

@kino2007 I'm not making a chat application. I'm actually using websockets with a multiplayer game, and the websocket wasn't getting a disconnect message, so when the user disconnected and reconnected due to the random error that everyone is talking about, it would give the character a new socket ID, and the old sprite with the old socket ID wasn't deleted because it was just getting a "transport close" message instead of a "disconnect" message.

At this point, even if I get a "transport close" message, I just delete the user from my list of current users the same way as if I got a "disconnect" message.

Same error here

After a quick search I found out that backo2 causes the error.

Then I used the dev version of socket.io and found out that the Socket.prototype.onevent throws the error.

I fixed it for me:

Previously I used this:

socket.on('ping', alert);

But then I changed it to this:

socket.on('ping', msg => {
    alert(msg);
});

And it worked!

I'm having the same problem. Any updates on this?

Same here.

socket.io & socket.io-client: "^2.1.1"
MacOS
Google Chrome is up to date
Version 68.0.3440.106 (Official Build) (64-bit)

I am having the same issue. Also, it's duplicating messages I send from server to client.

MacOS: 10.13.6
Socket.io: "^2.1.1"
Chrome: 68.0.3440.106

@abhyuditjain You can try reset all the listener's using socket.removeAllListeners(); to avoid multiple listener registrations which might cause the duplicating messages.

This seems to be an ongoing issue for several people and there has not been any solution to this. Any updates from anyone?

@vkotu If I remove all the listeners, then the socket doesn't reconnect to server on disconnect. Any way to fix this?

just use websocket- node, it is easy to use and works without any errors and plus you don't need an external library for that:
https://codeburst.io/why-you-don-t-need-socket-io-6848f1c871cd
https://medium.com/@martin.sikora/node-js-websocket-simple-chat-tutorial-2def3a841b61
https://www.npmjs.com/package/websocket

not an advertisement, just helping, unless you have a decision for this error :DDD it's been going on for months05.09.2018, 13:15, "Abhyudit Jain" notifications@github.com:@antoniab123456 This page is for posting issues about this repository. Kindly don't advertise over here.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

-- Sincerely, Antonia B. Customer Care Specialist @amoCRM Global 

Downgrading to 2.0.3 "fixed" this issue for me.

@cozuya going to test it. Will let you know if it worked!

Downgrading to 2.0.3 "fixed" this issue for me.

seems to be doing the trick. Tested for 4 mins and no errors. Let see how long it holds!

@cozuya thanks for posting this!

Same error in 2.1.1

Downgrading to 2.0.3 "fixed" this issue for me.

2.0.3 works for me! Thanks @cozuya

2.1.1 still facing the same issues. Tried to incrase ping and timeout but nothing changed

having the same issue in chrome with v2.1.1, while browser is idling for a long time (about 20-30 minutes)

2.1.1 still facing the same issues. Tried to incrase ping and timeout but nothing changed

downgrade to v 2.0.3

I have tried to use socket.io with 2.0.4, it looks normal.

I have found there is a change for the pingTimeout from 60000(v2.0.4) to 5000 (v2.1.1)

If I have changed pingTimeout to a larger number like 10000s, it seems working.

I guess it may relate to the browser idle where inactive tab will have some throttle.

I had some problem .Did someone solved the issue?

I had to downgrade too. It was not working for chrome and safari

Same problem here. Chrome under OSX.

I work around it not using socket.removeAllListeners(); but socket.off("whatever") for all my non-technical listeners besides "disconnect" and so forth. Works fine. The error messages in the browser console are annoying but not worth a downgrade for me.

I have to say it's disappointing to see this issue without any attention whatsoever. It's six month and counting.

So the reason for the reconnect is ping time out for me. Even with the downgrade I am still getting the error.

I completely agree such a huge library with extensive code base yet no attention to this issue !

Hope someone gets to it soon!

Sent from my iPhone

On Nov 28, 2018, at 2:14 PM, HorseBadorties notifications@github.com wrote:

Same problem here. Chrome under OSX.

I work around it not using socket.removeAllListeners(); but socket.off("whatever") for all my non-technical listeners besides "disconnect" and so forth. Works fine. The error messages in the browser console are annoying but not worth a downgrade for me.

I have to say it's disappointing to see this issue without any attention whatsoever. It's six month and counting.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Same issue.... surprised no fix has been made for this yet.

I to have run into this issue. In my case the disconnect was due to ping timeout. However, no luck on why the client side stopped responding to pings.

io.on('connection', function(socket) {
  socket.on('disconnect', function(reason) {
  console.log(`Socket disconnected for: ${reason}`);
  }
});

https://socket.io/docs/server-api/#Event-%E2%80%98disconnect%E2%80%99 has a list of reason for disconnections.

More Debugging:

One observation is that the ping event on the client is +30s from the last. Each and every time i saw the disconnect, its was 30s+ which is the default heartbeat interval + ping timeout. +26s, +28s, and +29s did show up without a disconnect.
When comparing against Safari, Safari was more consistent on pinging every 25s and did not see any disconnects.

There is a change for the default pingTimeout from 60000(v2.0.4) to 5000 (v2.1.0+) which is not enough for some browsers like Chrome.

The solution to this issue on v2.1.0+ including the latest v2.2.0 is to override the default pingTimeout on your server to a large value as follows:

const http = require('http');
const server = http.createServer();
const io = require('socket.io')(server, {
  pingTimeout: 60000,
});

OR

const io = require('socket.io')();
const http = require('http');
const server = http.createServer();
io.attach(server, {
  pingTimeout: 60000,
});

Why is 5000 not enough? I am seeing this issue on my local dev server, and the latency between the client and server is most certainly under that threshold. 5000ms seems like a reasonable timeout. Smells like there could be an issue with the ping-pong system itself, and it only manifested when it was lowered.

Thx for getting this thread started @getify (I'm on socket.io v2.2.0)

To anyone that is also experiencing this - ME TOO COMMENTS DON'T HELP :-) please vote up the issue with a thumb to show your support 👍

Thx @omardoma for discovering the pingTimeout and I agree with @LunarMist that the we should investigate the ping/pong event system.

I did some preliminary testing with Chrome, Firefox, & Safari (all on MacOS).

Chrome & Safari both appear to throttle ws activity with different behavior & constraints:

• Chrome, after ~5min of inactivity when the tab is focused or immediately when the tab goes into the background. This is intentional by the chromium team (https://developers.google.com/web/updates/2017/03/background_tabs)
• Safari, almost immediately when app focus is changed to another desktop app (MacOS) or when the tab goes into the background. Related to #2924
• Firefox, *never has any issues mentioned in this thread

Solutions

I tested for several hours with all 3 of these browsers, changing the pingTimeout & pingInterval values. What I found to be solutions:

1. Setting pingTimeout >= 30000ms
   
   
   
   • or -
   
   
2. Setting pingInterval <= 10000ms

I believe the best solution to be changing pingTimeout = 30000. The default pingInterval is 25000ms and increasing the frequency of the clients pinging the server to every 10s can be too chatty for _at scale_ projects.

Are @darrachequesne or any other repo members in favor of increasing the default pingTimeout to 30000 from the current default of 5000ms which was changed in v2.1 from 60000ms?

Reacting to your own comment also doesn't help.

The clients are the ones pinging the the server and not the other way around.

I think that's because the current version of socket.io relies on the setTimeout on the client side, which may not be as reliable as expected.

I think increasing the pingTimeout should temporarily fix the issue, but we'll use ping/pong from the server -> client (instead of the current client -> server) in v3.

Just use the following code at the client end.

_socket.on('ping', () => {
socket.emit(data);
});_

Thank you @crobinson42! Ping timeout solution worked great for me. I'm just having some concerns about that solution. If you lost internet connection in any moment, it will take up to 30 seconds for the disconnect event to be fired and for some apps, that's too much. e.g. a chat app that wants to disable text input when user is not connected.

In this case, increase the ping interval would do the work but as you said, the cost is high, is there any workaround for this?

Please let us know once this is fixed, same issue for me, my versions r below:

"socket.io": "2.2.0",
"socket.io-adapter": "~1.1.1",
"socket.io-client": "2.2.0",
"socket.io-parser": "~3.2.0",
"socket.io-redis": "^5.2.0",

My Code:
server, {
path: '/socket.io',
serveClient: true,
// below are engine.IO options
pingInterval: 40000,
pingTimeout: 25000,
upgradeTimeout: 30000, // default value is 10000ms, try changing it to 20k or more
agent: false,
cookie: false,
rejectUnauthorized: false,
reconnectionDelay: 1000,
reconnectionDelayMax: 5000
}

my client:

reconnection: true,
reconnectionDelay: 1000,
reconnectionDelayMax: 5000,
reconnectionAttempts: Infinity,
//our site options
transports: ["polling", "websocket"],
secure: true,
rejectUnauthorized: false,
forceNew: true,
timeout: 60000

Hello Faizan,
You can Have this Code Running as -
** I have Used the Same Version as Given By You..

Server Side - Code :

const server = require('http').createServer();
const io = require('socket.io')(server, {
// path: '/socket.io',
serveClient: true,

pingInterval: 40000,
pingTimeout: 25000,
upgradeTimeout: 21000, // default value is 10000ms, try changing it to 20k or more
agent: false,
cookie: false,
rejectUnauthorized: false,
reconnectionDelay: 1000,
reconnectionDelayMax: 5000

});

io.on('connection', function(socket) {
socket.emit('welcome', { message: 'Welcome!', id: socket.id });
socket.on('Sunil', console.log);
});

server.listen(3000);

Client Side Code :

var client = require("socket.io-client");
var socket = client.connect("http://localhost:3000", {
reconnection: true,
reconnectionDelay: 1000,
reconnectionDelayMax: 5000,
reconnectionAttempts: Infinity,
transports: ["websocket"],
secure: false,
rejectUnauthorized: false,
forceNew: true,
timeout: 6000
});

socket.connect();
socket.emit('Sunil', {
data: 'Hello'
});
socket.on('welcome', function (data) {
console.log(data)
socket.emit('Sunil', {
data: 'Faizan',
id: data.id
});

socket.disconnect();

});

Regard’s
Sunil Yadav

On 09-May-2019, at 4:05 PM, Faizan Zahid notifications@github.com wrote:

reconnection: true,
reconnectionDelay: 1000,
reconnectionDelayMax: 5000,
reconnectionAttempts: Infinity,
//our site options
transports: ["polling", "websocket"],
secure: true,
rejectUnauthorized: false,
forceNew: true,
timeout: 60000

Possibly a workaround on client side if anybody is interested till the issue is fixed. This will cause browser to not free up memory and may cause excessive memory usage.

• As listed here, https://apple.stackexchange.com/questions/344183/safari-12-mac-does-includeinternaldebugmenu-1-still-work, first grant Terminal app full disk access locally and restart terminal.
• Open a terminal window, and paste and run the command defaults write com.apple.Safari IncludeInternalDebugMenu 1
• Restart Safari. You will see a new Debug menu on right top.
• Under Debug->Miscellaneous Flags, enable two flags “Disable App Nap” and “Disable Hidden Page Timer Throttling” and restart Safari.

If anybody has Chrome workaround, that would help

You use Safari for localhost webdev? 🤔

You use Safari for localhost webdev? 🤔

Not really, but it is annoying with constant disconnects to test my app. This provides a temporary workaround till it is fixed in 3.0. This is not a solution. I posted if it will help somebody during dev.

I'm using very low pingInterval and pingTimeouts to get realtime offline status changes, setting it to 30 seconds would break my flow... does anybody know a way to solve this issue so I can use the long timeout 'fix' for backgrounded browser tabs?

Any updates on this?

I'm using very low pingInterval and pingTimeouts to get realtime offline status changes, setting it to 30 seconds would break my flow... does anybody know a way to solve this issue so I can use the long timeout 'fix' for backgrounded browser tabs?

You should is the disconnect events on the socket to handle presence, when the socket disconnects, find the user and mark them as offline in your datastore

Here are the defaults from the documentation. Looks like a ping is sent every 25 seconds and each ping has 5 seconds to complete.

pingTimeout | 5000 | how many ms without a pong packet to consider the connection closed
-- | -- | --
pingInterval | 25000 | how many ms before sending a new ping packet

I noticed this same error but in a different context so I'm going to do a quick write-up with my problem and solution for anyone else ending up here.

My scenario was on Chrome for Android where the connection is dropped after locking the screen.

I'm using a token to identify the same user across different connections, which I send from client on connect using the query option approach and I update the token with a new one received from server:

// client
io('myAppUrl', {
  query: {
    token: localStorage.getItem('myKey') || ''
  }
});

io.on('reconnect_attempt', () => {
  io.opts.query = {
    token: localStorage.getItem('myKey') || ''
  };
});

io.on('my_custom_connection_successful_event', (token) => {
  localStorage.setItem('myKey', token);
});

The problem is that the Chrome for Android client would send to the server an empty string token on reconnect. Which I wouldn't expect since I added the 'reconnect_attempt' listener which makes sure to set the latest token from localStorage.

Well after a couple of hours of debugging with console logging all the possible client events I realized that the 'reconnect_attempt' event is not fired at all in my scenario of reconnecting. After unlocking the screen I get the following sequence of events:

• disconnect (reason: 'transport close')
• reconnecting (attempt: 1)
• reconnect
• ping/pong starts again

So no 'reconnect_attempt' event is being fired which explains why the token is still empty string (the initial value set on connect).

Long story short, the solution for me is to immediately update the io.opts.query instance variable on my custom "connection successful" event received form the server with the new token:

// client
io('myAppUrl', {
  query: {
    token: localStorage.getItem('myKey') || ''
  }
});

io.on('my_custom_connection_successful_event', (token) => {
  localStorage.setItem('myKey', token);
  io.opts.query = {
    token: token
  };
});

Now I understand that io.opts.query is an instance variable which is used on connect and all subsequent reconnects, so I can update it as soon as I want to. I don't have to wait for any reconnect-related event.

I feel a bit misled by the With query options docs. Maybe I misunderstood the use case in that example? But if it's similar to my use case, instead of the 'reconnect_attempt' example the docs could explain that io.opts.query is an instance variable that can be mutated and its current value is used on all subsequent reconnects. So it can be changed whenever you want to refresh the token, even on a 'refresh_token' custom event for example. I can do a PR if you think it's a good idea for improving the docs.

Edit:
Upon further investigation I realized my mistake was that the 'reconnect_attempt' listener was being removed from another part of my code... :man_facepalming: That's why I was not seeing it in my logging. So yes, the events sequence for my reconnect scenario is in fact:

• disconnect (reason: 'transport close')
• reconnect_attempt (attempt: 1)
• reconnecting (attempt: 1)
• reconnect
• ping/pong starts again

Still, my realization that io.opts.query can be changed whenever you want is still valid. :sweat_smile:

Is it still ok to downgrade ? I switch on 2.0.3 but it doesn't seem to work.

Hello, I am facing the same kind of issue but with two errors. I tried @omardoma solution. Can anyone help?
Os - Ubuntu 18.04
Node - 12.16.2
npm - 6.14.5
socket.io - 2.3.0
my code -

app.js

const speech = require('@google-cloud/speech');
const speechClient = new speech.SpeechClient(); // Creates a client
const environmentVars = require('dotenv').config();
const io = require('socket.io')();
const http = require('http');
const server = http.createServer();
io.attach(server, {
  pingTimeout: 60000,
});



console.log(io)



// =========================== SOCKET.IO ================================ //

io.on('connection', function (client) {
  console.log('Client Connected to server');
  let recognizeStream = null;

ejs file

<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.3.0/socket.io.js" integrity="sha256-bQmrZe4yPnQrLTY+1gYylfNMBuGfnT/HKsCGX+9Xuqo=" crossorigin="anonymous"></script>
<script src="/js/client.js"></script>

js file

const socket = io.connect("http://localhost:8080");

I am using socket.io version 2.3.0. I use a websocket connection to client. When my client has a browser alert(which is synchronous) in UI and if user does not dismiss the alert for more than 30 sec(pingTimeout + pingInterval), I see the 'Websocket is already in CLOSING or CLOSED state' message and get a disconnect event with pingTimeout reason. I do not want this websocket to disconnect when UI has an alert. If I increase the pingTimeout to 10 min, the disconnect does not happen for 10 min. But from what I read in the comments above, this may have a negative impact(the client may not know there was a disconnect until 10min). But I noticed that if there is a network interruption etc., we get a disconnect with transport close reason. So is it okay to increase this pingTimeout+pingInterval? Is there a specific scenario when a disconnect is undetected? Or is there any other way to fix this?