sess integration lost when VS Code restores an R terminal

[grcatlin]

After reopening VS Code with an R terminal still present, sess may fail to reconnect. View() and plots then open in native windows instead of VS Code. This reproduces on macOS as described below.

1. Open a directory in VS Code - be sure there are no active terminals.
2. Create an R terminal r.createRTerm. [sess] Connected to VS Code should be printed. View() and plot() should work as expected.

3. Quit VS Code without closing the active R terminal. Or swap to a different directory workbench.action.openRecent (ctrl + r) without closing the active R terminal.
4. Open VS Code again or ctrl + r back to the original directory, sess shows an IPC error.

5. Run the same commands as earlier. Now, XQuartz pops up instead.

Originally posted by @grcatlin in #1794

As I mentioned earlier, I can fix it by killing the old terminal and then making a new R terminal. Oddly, I cannot reproduce this on Windows. The same error occurs using both arf (above) and the base R console.

[Fred-Wu]

How does you R process survive after closing VS Code?

Cannot speak for arf, but I don't think R's native console can survive from VS Code shutdown and reopen. The behaviour is expected because the sess connection is gone completely in this case.

At the moment, I think sess reconnection is only for VS Code reload, not VS Code completely restart.

[grcatlin]

You're right: R does not survive a full VS Code shutdown. VS Code restores the terminal, not the R process itself.

VS Code distinguishes process reconnection on window reload from process revive on application restart. With persistent terminal sessions enabled, revival relaunches the terminal process using its saved environment. In this case that starts a new R process, whose profile calls sess::connect() with the old SESS_DISCOVERY_FILE. The file may still name the previous extension host's IPC endpoint, or the new endpoint may not be listening yet. The one-shot startup connection fails, leaving View() and plots outside VS Code. So this is a startup/recovery problem as well as the existing live-process reconnection case.