Users not showing in user list

[mrneil]

First off, let me say thank you to all involved in this project. We've been running it for almost three months and it is fantastic! It makes our operation, one which relies heavily on collaborative editing, very smooth.

Problem

We're running master branch commit 309e3b0 and have noticed an occasional issue where a user will be connected as normal, but that user does not appear in the user list. When this happens, everything else operates normally, i.e. the user can see the changes others are making, others can see the changes the affected user is making, chat messages are functioning, etc. Etherpad Lite will operate in this mode for quite a while, not just a few seconds. If any of the other users refresh their browser, their user list will be complete again (but only theirs, not any users who have not refreshed).

Potential Cause

The problem may originate around duplicate user detection in PadMessageHandler.js. (I may have some incorrect terminology here, but I can provide debug logs if necessary.) When a user loads a pad, a CLIENT_READY message is sent. If the author ID is a duplicate of an existing session, that session is sent a "disconnect":"userdup" message, the new session takes over, and USER_NEWINFO messages are sent to all users. But eventually, socket.io times out on the original session and sends USER_LEAVE messages, removing the user from all user lists even though the new session is still connected.

Next Step

I do not have enough experience to attempt a fix on my own, but perhaps this will provide a start for someone with more knowledge of Etherpad Lite. I'm happy to provide help where I can.

EDIT - Updated link to match commit I'm using.

[fourplusone]

I think its a race condition. USER_LEAVE is being sent everytime a client disconnects, even if user_dup has been sent. So if USER_LEAVE arrives after USER_NEWINFO the client will be removed from the list

[mrneil]

That is exactly what I'm seeing in the logs. In today's case, about 24 seconds passed between the userdup and USER_LEAVE messages. Of course, during that time, the USER_NEWINFO message was sent.

I just got an idea. What if before any USER_LEAVE messages are sent, Etherpad Lite loops through the other existing sessions to see if any author IDs match the user that is supposedly leaving? Then only send the USER_LEAVE messages if there are no matches.

It would be something like this, inserted at line 102 of PadMessageHandler.js:

var authorConnected = false;

for(j in pad2sessions[sessionPad])
{
  if (pad2sessions[sessionPad][j] != client.id &&
      sessioninfos[pad2sessions[sessionPad][j]] &&
      author == sessioninfos[pad2sessions[sessionPad][j]].author)
  {
    authorConnected = true;
    break;
  }
}

if (!authorConnected)
{
  ...
  // existing PadMessageHandler.js lines 102 to 134 that create/send USER_LEAVE message
  ...
}

The third line might need some work. I'm not sure if those are the right arrays to be using.

I'm not in a position to test this at the moment, but does anyone see any problem with it?

EDIT - Updated code to catch stuff I missed. It runs and functions properly for a regular disconnect or duplicate user scenario, i.e. one where this issue doesn't occur. I'd still appreciate feedback to see if this is a valid way to go about fixing the problem though.

EDIT - Updated links and line numbers to match commit I'm using.

[mrneil]

An update: I added the code above to our installation of Etherpad Lite about a month ago (with a line to log a message when authorConnected was set to true) and it seems to be working quite well.

I'm still interested in any feedback from more experienced developers as to whether the code above is a valid way to fix it or if there could be any side effects.

Until I get more info (and learn more about git), I will not be making a pull request for this change. If someone else wishes to, go for it. I only ask that you let me know you've done so.

[mrneil]

I ran into a slight issue today and I've edited the code above to account for it. (Now checking for a valid sessioninfos[pad2sessions[sessionPad][j]] before trying to access the "author" property.)

[marcelklehr]

This seems to be very old. Please reopen this issue, if you've still got problems with the latest version