Closed jmcphers closed 12 hours ago
Tested with a local dev build of Positron Server Web on Mac. Video shows R session outside of a folder, but I also tested within a project folder and with Python.
https://github.com/user-attachments/assets/fdcbad8d-5aff-46fb-b91f-bacba63b9a67
Waiting on a local build to test this in Workbench as well.
I'm not sure we expect that to work?
No, this definitely does not work today. We do need to fix this up, either by marking the session in the "old" tab as defunct, or by allowing two different IDEs to connect to the same session (I can file an issue). But this PR doesn't attempt to do either one.
(edit: filed as https://github.com/posit-dev/positron/issues/5374)
FWIW the Terminal tab has very nice behavior here -- if you try opening two different browser tabs with the same terminal, you'll see commands and output reflected in both!
Posit Workbench 2024.12.0-daily+364.pro11, “Kousa Dogwood” (9de4d019)
Video shows Python session outside of a folder, but I also tested within a project folder and with R.
https://github.com/user-attachments/assets/fcb775bb-4c06-488e-b1a8-4d072adf4896
There is some weirdness when switching folders. I didn't notice this previously, but I can now reproduce it in Positron Server Web as well.
This video is not very concise. You can skip to 1:30.
https://github.com/user-attachments/assets/20a29674-2422-4bce-8869-65882f60c1eb
I was seeing duplicate interpreters in the Console and Interpreter dropdowns, but not anymore after the recent commits. This is what I was previously seeing:
I'm able to get out of a broken interpreter state much more easily now. I'm still hitting a case where switching folders causes a reconnect failure in my Consoles (skip to ~0:45), but I may be in a weird state after testing a bunch of things. If it isn't easily reproducible by others, then I think we're good to go on this!
https://github.com/user-attachments/assets/6bb4e6d7-1e98-4815-8f38-328cd5092b06
Posit Workbench 2024.12.0-daily+375.pro4, “Kousa Dogwood” (123323c8)
https://github.com/user-attachments/assets/c2fafbab-6f5c-4178-be8e-034ba2783f6d
https://github.com/user-attachments/assets/366e2fe0-d5cf-4e03-b63c-55dc06be8a8a
This change fixes some issues around reconnecting to Python and R after various actions that unload the UI (browser refresh, loading in a new tab, closing a tab and coming back, reloading the desktop UI, etc).
The underlying issue is that we remember which Python and R sessions are running by saving a list of active sessions into VS Code's workspace storage. Unfortunately, workspace storage is not a suitable place to put these things, because it is too durable -- it hangs around even when Positron is closed -- and, in browser mode, it can also be shared among workspaces when switching folders. Previous iterations of this change tried to work around these problems by adding additional metadata or clearing out the storage in some situations, but we were not able to find a solution that covered all the edge cases.
To address this holistically we need a place to store the list of sessions that is unique to the workspace and the session -- that is, it has the same lifetime as the server process that hosts Python and R.
This change adds that, in the form of a new service called an "Ephemeral State Service". This service provides a way to store state that is ephemeral (compared to the durable
IStorageService
) but needs to persist across a user session, through browser refreshes and disconnects/reconnects.We store the list of active sessions in this new service, so that the session list has the same scope as the sessions themselves.
Addresses https://github.com/posit-dev/positron/issues/5267.
QA Notes
This affects the way we remember which interpreter sessions are running across all of Positron's various configurations. We don't have to test every member of this matrix, but it wouldn't hurt to try to get a representative sample:
Lifecycles:
Environments:
Targets:
The main class of errors will be either (a) attempts to reconnect to sessions that don't exist, and (b) failure to reconnect to sessions that do exist. In either case the most helpful logs are from the Developer Tools as that's where most of this code logs.