Positron Workbench: Going back into a session starts new interpreter env

[jonvanausdeln]

System details:

Positron and OS details:

Ubuntu 24
Positron 2024.11.0-140
Workbench 2024.11.0-338.pro1

Interpreter details:

R 4.4.1
Python 3.10.10

Describe the issue:

Going back into an existing Positron session starts a new interpreter environment. This does not happen when just refreshing the tab, only when re-enter the session from Workbench launcher screen.

Screen.Recording.2024-11-04.144103.mp4

Steps to reproduce the issue:

1. Start a new Positron Session
2. Start the R console & create a variable. eg. x <-1
3. Return to Workbench launcher screen and re-enter session

A new R env is created, losing old data.

Expected or desired behavior:

The session would persist and the R data would still be present

Note.. the terminal pane seems to persist

Were there any error messages in the UI, Output panel, or Developer Tools console?

[jmcphers]

• Do recent Workbench state changes fix this? (probably not but worth testing)
• Does this reproduce when a folder is open? (the no-folder state is a special case for workbench state)

[sharon-wang]

I built Workbench locally from main with the latest state changes and ran with Positron 2024.11.1 build 4.

• Do recent Workbench state changes fix this? (probably not but worth testing)

Nope :( didn't fix this.

• Does this reproduce when a folder is open? (the no-folder state is a special case for workbench state)

Yes, this issue still occurs when a folder is open.

---

If I copy the url of the Positron tab and paste the url in a new tab, the same issue occurs. So there's some state being lost or not getting reloaded properly when we open up an existing Positron session in a new tab.

Will be investigating further.

[sharon-wang]

If I copy the url of the Positron tab and paste the url in a new tab, the same issue occurs.

This is reproducible in Positron Server Web. Pasting the url in a new tab should be more or less equivalent to clicking the session from the Workbench launcher screen.

---

When running VS Code in Workbench, Jupyter Interactive Console sessions are also lost when re-opening the session from the Workbench launcher screen. Reloading the tab or opening the url in a new tab causes the Jupyter console variables to be lost as well.

Steps:

• start a VS Code session
• install the Jupyter extension if it isn't already
• open the plotly-example.py
• click the Play button context menu and select Run Python File in the Jupyter Interactive Console
• run the file
• click on the Variables button in the Jupyter Interactive Console to see the fig variable
• reload the tab / open the session url in a new tab / re-open the VS Code session from the Workbench launcher page
• see that the session variables are lost and/or the console session errors out

[jmcphers]

This is happening due to this code:

positron/src/vs/workbench/services/runtimeStartup/common/runtimeStartup.ts

Lines 698 to 704 in 909d8b6

	// Don't attempt to restore sessions if we're not reloading
	if (this._lifecycleService.startupKind !== StartupKind.ReloadedWindow) {
	// Clear any sessions that may have been saved from a previous
	// window.
	this.clearWorkspaceSessions();
	return;
	}

It turns out that for Positron on Workbench, it is considered a "new window" whenever we reconnect (probably not a bug), so we're removing all the persisted R and Python sessions when we enter the codepath above, causing Positron to orphan the existing sessions and boot new ones.

We do need some variant of this behavior however! Without it, Positron tries to reconnect to old sessions if e.g. you end your Positron session and start a new one in the same workspace. That's a problem in both Desktop and Server spins of the system.

So the key problem is that we need to save the set of active R and Python sessions that persists within a Positron session but not across Positron sessions in the same workspace. The underlying storage service doesn't have any session scope, so we may need to consult other sources or change the way these are read/written.

[jmcphers]

I took a look at how the Terminal tab handles this, since it solves an almost identical problem, and discovered (to my dismay) that ultimately it works by querying the PtyHost from the front end, e.g. here:

positron/src/vs/workbench/contrib/terminal/electron-sandbox/localTerminalBackend.ts

Line 369 in 909d8b6

return this._proxy.getTerminalLayoutInfo(layoutArgs);

We can't take this approach in Positron (as it stands) since we have insulated the supervisor from the front end too well -- there is no way for the front end to talk to it.

Here are some possible ways around this problem:

• Stop trying to do everything in extension-land. Instead of having the supervisor run under the PtyHost, have it run alongside it, and allow Positron to query it directly, as it can the PtyHost. This feels the most complete as a solution, but would require a lot of additional infrastructure.
• Don't worry about persisting sessions too long; instead, provide a way to do a pre-flight check on a session to see if it's still running before we try to reconnect to it. At startup, check the persisted sessions before reconnecting to them. This is kind of gross, because it complicates startup even more, and it means we are going be recovering and cleaning up from stale data often, which smells bad from a design standpoint.
• Flip the script on session persistence: instead of having Positron maintain the list of sessions and ask the extensions to reconnect to them, have the extensions expose a way for Positron to ask them what is currently running. The supervisor extension can query the supervisor directly to get this list.
• Run away from home and live in the woods

[jonvanausdeln]

Verified Fixed

Positron Version(s) : 2024.12.0-80
Workbench Version(s):2024.12.0+456.pro3
OS Version(s) : Ubuntu 24

Test scenario(s)

• Start R & Python consoles
• Create a few variables
• Close tab
• Return to session

INterpreter session reconnected. Variables were still present, etc.

Link(s) to TestRail test cases run or created: