Reattached to the wrong terminal

I just reloaded a window with my vscode-jupyter repo open, and it attached to a terminal which is already open in my vscode repo, so now this terminal is open in two windows:

The right window is the window that originally owned this terminal

One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.

[Tyriar]

Ok, I figured this out. What a journey! Here is the fairly reliable repro:

• Clear state
  • ./scripts/code
  • Given 2 folders a and b
  • Open folders a and b and close all terminals
  • File > Exit
• Setup for the process revive
  • ./scripts/code
  • Window a: Open 3 terminals and type “a”, “b”, “c” into them respectively, this helps identify them to ensure they’re in the correct order later
  • Window b: Open 3 terminals and type “d”, “e”, “f” into them respectively
  • File > Exit
• Process revive
  • ./scripts/code
  • Window a and b should revive the processes and have all terminals in the correct order they were created (this works)
• Process reconnect
  • Reload window a and window b at the same time
  • Window a and b should revive the processes and have all terminals in the correct order they were created 🐛

Note that this is a timing issue and has a chance to not reproduce the problem.

---

This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn’t matter when reviving.

[2022-08-09 10:37:37.588] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 2 -> newId 1
[2022-08-09 10:37:37.590] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 3 -> newId 2
[2022-08-09 10:37:37.591] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 4 -> newId 3
[2022-08-09 10:37:37.598] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 1 -> newId 4
[2022-08-09 10:37:37.600] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 5 -> newId 5
[2022-08-09 10:37:37.600] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 6 -> newId 6
[2022-08-09 10:37:37.700] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 2 -> revivedPtyId 1
[2022-08-09 10:37:37.700] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 3 -> revivedPtyId 2
[2022-08-09 10:37:37.701] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 4 -> revivedPtyId 3
[2022-08-09 10:37:37.701] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 1 -> revivedPtyId 4
[2022-08-09 10:37:37.701] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 5 -> revivedPtyId 5
[2022-08-09 10:37:37.701] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 6 -> revivedPtyId 6

After that, when reloading windows, terminal processes do not get revived but reconnected to. So an undefined mapping is expected:

[2022-08-09 10:48:20.084] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 1 -> revivedPtyId undefined
[2022-08-09 10:48:20.084] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 2 -> revivedPtyId undefined
[2022-08-09 10:48:20.084] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 3 -> revivedPtyId undefined

What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a newId that is mapped to a different pty ID in _revivedPtyIdMap, it will reconnect to that one instead:

[2022-08-09 10:40:41.894] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 2 -> newId 1
[2022-08-09 10:40:41.896] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 5 -> newId 2
[2022-08-09 10:40:41.896] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 6 -> newId 3
[2022-08-09 10:40:41.960] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 2 -> revivedPtyId 1
[2022-08-09 10:40:41.960] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 5 -> revivedPtyId 2
[2022-08-09 10:40:41.960] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 6 -> revivedPtyId 3
[2022-08-09 10:40:42.073] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 1 -> newId 4
[2022-08-09 10:40:42.074] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 3 -> newId 5
[2022-08-09 10:40:42.075] [ptyhost] [info] reviveTerminalProcesses', 'terminal id 4 -> newId 6
[2022-08-09 10:40:42.154] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 1 -> revivedPtyId 4
[2022-08-09 10:40:42.154] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 3 -> revivedPtyId 5
[2022-08-09 10:40:42.154] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 4 -> revivedPtyId 6

The above results in:

2 -> 1
5 -> 2
6 -> 3
1 -> 4
3 -> 5
4 -> 6

Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect to the wrong pty.

[2022-08-09 10:40:53.471] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 4 -> revivedPtyId 6
[2022-08-09 10:40:53.471] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 5 -> revivedPtyId 2
[2022-08-09 10:40:53.471] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 6 -> revivedPtyId 3
[2022-08-09 10:40:53.507] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 1 -> revivedPtyId 4
[2022-08-09 10:40:53.507] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 2 -> revivedPtyId 1
[2022-08-09 10:40:53.507] [ptyhost] [info] _expandTerminalInstance', 'terminal ID 3 -> revivedPtyId 5

So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window’s ptys:

2 -> 1 -> 4
5 -> 2 -> 1
6 -> 3 -> 5
1 -> 4 -> 6
3 -> 5 -> 2
4 -> 6 -> 3

[^1]: The folder’s terminals may not get restored at with the warning “Couldn’t get layout info, a terminal was probably disconnected” in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.

[meganrogge]

Yep, it’s not working atm for remote terminals, so:

terminal.integrated.enablePersistentSessions: false