You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Correctly support reconnection with multiple windows #1950
First I am not sure if this is supported, but I have a VS code instance behind a reverse proxy so that might be where the actual issue lives. The issue is that if I open a new window and then open a different project in that window after some time all websocket activity seems to stop. Like the terminal won't respond. If I reload the window everything comes back and it is just fine.
So:
a) is this a supported activity?
b) is this a bug with code?
c) is this an issue with traefik, if so how might I debug that to rule out vscode?
Multiple windows are supported but I think if the connection is interrupted only one window will reconnect. That might be what's happening here.
Right now whenever a connection disconnects it goes into an offline queue. Then when a new connection or a previously offline one comes in we discard all the other offline connections. This prevents building up connections that will never come back (every time you refresh or close the page that connection will never come back).
So I think we'll want to rework this a little. If we only discard offline connections when a new connection comes it that should have all the same behavior as the current implementation while fixing this specific issue, I think.
The best solution though would be if VS Code could just reconnect without requiring existing state on the server.
That might be what is happening. I sometimes connect to the same instance with two different projects each on their own computer. (Yes I am one of those meatheads). Anyway, I use traefik with forward-auth, so those browser sessions could timeout at different times. Might that mess it up?
I wonder if there is a way to have a token (or a unique hash) on the URL. So something like a browser reload would reconnect correctly. I have that in another project. We keep a token that we provide each websocket connection so we can reestablish a session connection that might have gone away. That being said I am not sure this is worth the complexity it might introduce. Too bad we don't have the server-side equivalent of service workers =)
Yup I think it should still be OK in that scenario with the proposed fix. The connection cleanup logic is independent of whether the connections are from the same browser or even the same computer.
There could still be a problem though where if a new connection was made while another connection was temporarily offline it would wipe that connection out (for example refreshing one tab just as another one got disconnected and was undergoing a reconnect).
I like the hash idea; we could use that to solve the refresh angle of the above edge case completely. Although we can't reconnect to the exact same session since it requires client-side state (which is lost in the refresh) we can at least replace the old session and skip discarding other offline sessions.
Then the only edge case would be making a completely new connection while other connections are temporarily offline (like a new tab, new browser, new computer, etc). To help alleviate this maybe we could also add a small timeout before discarding offline connections in case they come back soon along with a maximum offline connection limit.
Maybe there is a better algorithm for garbage collecting offline connections though. It might be worth the engineering effort to make VS Code reconnects stateless so we don't have to do any of this and can just connect whenever.
changed the title [-]Multiple windows with different projects question (maybe is a bug)[/-][+]Correctly support reconnection with multiple windows[/+]on Aug 17, 2020
Activity
code-asher commentedon Aug 7, 2020
Multiple windows are supported but I think if the connection is interrupted only one window will reconnect. That might be what's happening here.
Right now whenever a connection disconnects it goes into an offline queue. Then when a new connection or a previously offline one comes in we discard all the other offline connections. This prevents building up connections that will never come back (every time you refresh or close the page that connection will never come back).
So I think we'll want to rework this a little. If we only discard offline connections when a new connection comes it that should have all the same behavior as the current implementation while fixing this specific issue, I think.
The best solution though would be if VS Code could just reconnect without requiring existing state on the server.
geiseri commentedon Aug 9, 2020
That might be what is happening. I sometimes connect to the same instance with two different projects each on their own computer. (Yes I am one of those meatheads). Anyway, I use traefik with forward-auth, so those browser sessions could timeout at different times. Might that mess it up?
I wonder if there is a way to have a token (or a unique hash) on the URL. So something like a browser reload would reconnect correctly. I have that in another project. We keep a token that we provide each websocket connection so we can reestablish a session connection that might have gone away. That being said I am not sure this is worth the complexity it might introduce. Too bad we don't have the server-side equivalent of service workers =)
code-asher commentedon Aug 10, 2020
Yup I think it should still be OK in that scenario with the proposed fix. The connection cleanup logic is independent of whether the connections are from the same browser or even the same computer.
There could still be a problem though where if a new connection was made while another connection was temporarily offline it would wipe that connection out (for example refreshing one tab just as another one got disconnected and was undergoing a reconnect).
I like the hash idea; we could use that to solve the refresh angle of the above edge case completely. Although we can't reconnect to the exact same session since it requires client-side state (which is lost in the refresh) we can at least replace the old session and skip discarding other offline sessions.
Then the only edge case would be making a completely new connection while other connections are temporarily offline (like a new tab, new browser, new computer, etc). To help alleviate this maybe we could also add a small timeout before discarding offline connections in case they come back soon along with a maximum offline connection limit.
Maybe there is a better algorithm for garbage collecting offline connections though. It might be worth the engineering effort to make VS Code reconnects stateless so we don't have to do any of this and can just connect whenever.
[-]Multiple windows with different projects question (maybe is a bug)[/-][+]Correctly support reconnection with multiple windows[/+]stale commentedon Oct 27, 2021
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.