Vscode-extension-for-zowe: Unexpected errors when switching between different workspaces in Eclipse Che

[venkatzhub]

Scenario:

1. Created and launched a workspace with name "Demo"
2. Created a Profile CA32 using the + sign, did a search for data sets: BALVE05.TEST.*
3. Three datasets matching the criteria displayed.
4. Added each of those data sets to Favorites
5. Stopped this workspace
6. Created a new workspace with name "Demo 2"
7. When Demo 2 initializes, there is an error message displayed (I was not able to capture it), but here is the gist of it " There are Favorites using the profile CA32, so to use them you need to create a profile with the same name ", in addition to this there is an informational message saying " you do not have a default Zowe profile, so you need to create one "

There are no datasets listed under Favorites to start with. There are no datasets listed under Favorites if I create a profile with the same name CA32 or a new one.

Also - when creating a new profile in the new workspace using the + sign, the profile created in the "stopped" workspace is displayed.

Is this the desired behavior? Is the profile information created in one workspace being remembered in other workspaces natural? Similar q about favorites.

Note:The behavior is the same if I stop a workspace OR delete and create a new one, which is weirder, because that workspace is Deleted, so anything I did in that should not be remembered.

[venkatzhub]

Even the User preferences are remembered from the Deleted workspace.

[venkatzhub]

[phaumer]

This also related to issue: https://github.com/zowe/vscode-extension-for-zowe/issues/528
The favorites parsing code should allow non-existing favorites without throwing errors.
But the solution requires a bit of thinking about what to show, how to do clean-up etc.
The simplest approach is to just not show these and have the user clean them up in the settings file if they want to.

[venkatzhub]

@phaumer - thanks! Does that take care of just the favorites? Based on what I saw its more than favorites - basically the notion of a workspace should be honored, so the metadata being persisted should follow the lifecycle of a workspace.

[phaumer]

The CLI profiles are stored in ~/.zowe and the favorites are stored in ~/.vscode. Are you talking about VS Code workspaces or Che workspaces? The Che workspaces need to be configured so that CLI and VS Code use the same container for storing these files. Otherwise we run into use cases that require special handling just for Che, which I think we should avoid as much as we can. In some cases where it was not avoidable such as dealing with temp directories with Zowe-Temp-Folder-Location we found a solution to provides value for both platforms.

[venkatzhub]

For my specific scenario, I was talking Che. Did not try VSCode, but will do. My Che instance is configured to use the same container. It is a good desire to not have special handling for Che and VSCode, at the same time, they should not behave differently either.

So coming back to the issue, if I use the same container, this problem should NOT occur in Che?

[ghost]

You are correct, this problem should not occur in Che. I believe it is a problem with the current Che4z stack, where settings like Zowe-Temp-Folder-Location are set at the "Workspace" level, but should be set at the "User" level instead.

[ghost]

Sorry, my previous response was only referring to the "Zowe-Temp-Folder-Location" setting, hadn't read the original comment closely enough.

Regarding the issue of profile info being shared across workspaces, that is happening because Zowe Explorer saves its settings (like profile history and favorites) in the VSCode/Theia user settings file. In Theia, the user settings file is identical across all workspaces that the same user has.

Not aware of any easy way around this, unless we make Zowe Explorer save its settings elsewhere. This might be worth looking into, considering other VSCode extensions it doesn't seem typical to save data like history/favorites in the user settings.

[venkatzhub]

No worries @tjohnsonBCM. The key is we need to look into this. Knowing what we store where - would be good to iron out in this kinda early stage.