Here's the use case I am trying to solve for: A user submits a form to a long running server-process. That process uses socket.io to report back to the browser the current status of the long-running process (step 1...step 2...step 3...).
NOW, the user closes their browser, goes away, and comes back 2 minutes later. The long-running process is still working in the background, but now the client socket.io connection knows thinks a new sessions as begun.
I can of course detect this situation on the backend, where I just end that request and tell the user to come back later (crappy solution), but I would really like to re-establish the socket.io connection with old long-running process if it is still running, or even if I am thinking about this in the right way. But I have to be able to support the user breaking the client connection and coming back later.
So, I got it working one way: when this condition is detected, I turn the session into a listener of the database state persisted by the long-running process, and emit messages back as though imitating the primary process.
To elaborate: I add a report status field to the db that tracks the progress of the report gen for each user. When the user logs in, I check the user_id against the backend database to see if their report is in process. When that happens, the server-side goes into listening mode, polling the database ebery 5 seconds for an update to the report status and reporting that status back to the client until the report is generated, or 5 hours passes (hard limit to releases processes if something else goes wrong).