LSP features does not work in another directory

[sergiuilie]

Describe the bug

Our product is an LSP server for COBOL language. Theia editor usually opens in ./projects folder and our LSP features work normally, nothing new so far. The problem is when you open a file that is sitting in another directory located at top level from ./projects.
Example: I have the following directories structure
bin boot dev entrypoint.sh etc home lib lib64 media mnt opt plugins proc projects root run sbin srv sys tmp usr var workspace_logs

if I will open the file under .tmp some of our features stop working. Please take a look at the following gif:

This behavior is not present on Theia vanilla and it is reproducible for HLASM, COBOL, JAVA LSPs.
Can not reproduce it on che-theia:7.3.3.

This error I am getting in the console log:

Che version

• latest
• nightly
• other: please specify

Steps to reproduce

Expected behavior

Runtime

• kubernetes (include output of kubectl version)
• Openshift (include output of oc version)
• minikube (include output of minikube version v1.6.2 and chectl version chectl/0.0.20200214-next.75e7903 win32-x64 node-v10.19.0)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify)

Installation method

• chectl
• che-operator
• minishift-addon
• I don't know

Environment

• my computer
  • Windows
  • Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • other (please specify)
• other: please specify

[tsmaeder]

@sergiuilie when you say it works in Theia proper, what is the procedure to test that?

[sergiuilie]

I build and run Theia browser example, in the plugins folder I attached our extension .vsix and I repeated the steps described above, open a document that doesn't stay on /projects directory but one level up.

[tsmaeder]

Do you "Open folder" and chose the "/projects" folder? One notable difference we have with vanilla Theia is that we have a fixed workspace root. How exactly do you open the file outside "/projects"? File->Open File menu?

[sergiuilie]

Not exactly, one of our extension which is available on marketplace Code4Z contains an application called Zowe which pulls a file from mainframe and save it under temporary folder which is one level above /projects, this is how we test it if you would like to have a demo about this than we may have a call.

[tsmaeder]

Sure, can you ping me on Eclipse mattermost to set up a meeting? I'm @tsmaeder

[tsmaeder]

Had that meeting, and it seems the file is being opened automatically after being downloaded. A quick look at some error messages seems to indicate that the being used in the completion request is correct and that the file being opened is present in the container running the language server.
The error ("there are no document for ${resource}" seems to indicate that the plugin has never been informed that the file has been opened. So either it's being informed under a different uri or there is some filtering going on or the proper API to open the file is not being used.

[tsmaeder]

@sergiuilie you said you had a reproducer based on Java?

[sergiuilie]

1. Open Eclipse CHE and select a java maven workspace
2. Check that LSP works on the default project which lays under /projects
3. Add a new workspace to the folder, select /tmp, check if you have write access to this directory
4. Create a new class called Untitled.java, code some java and make a typo in the java class name, wait for the LSP to publish diagnostic
5. Once LSP is active try using auto-complete
6. You should be able to see the error in the console

Please let me know if you are able to reproduce it, I just tested it before posting

[tsmaeder]

Well, that's not really the same case: if you open /tmp in the IDE, you're opening a folder inside the theia container. It is normal that this cannot be found in the plugin sidecar where the Java support is running: the file system is not shared.
I still think it's a real issue you showed me, but this case is not it. I think we'll have to test with your original plugin, somehow.

[tsmaeder]

So the question really is: how do you open the file at all? Do you copy it to both theia:/tmp and java:/tmp? What API do you use to display the downloaded file?

[filipkroupa]

@tsmaeder I don't think there was any change regarding exposure of folders to sidecars (eg. the /tmp folder from Theia container), it has been always set this way in previous Che-Theia versions. But this issue did not exist there, so I don't think the folder exposure can be the root cause here.
I see this as a regression, since the issue started with Che-Theia 7.4.0. If you try running with Che-Theia 7.3.3, the issue is not present and COBOL LSP works as we expect.

[tsmaeder]

Well it's not a regression in the sense that the /tmp folders are not intended to be shared between the containers. If that is what the problem really is. But I don't know what's going on, t.b.h.

[filipkroupa]

I don't think this issue is even related to sharing the folders. LSP protocol does not works this way. Only the LSP client part, which exists inside Theia, needs to access the file represented by URI. The file contents is provided to the LSP server via RPC (that is how the protocol is defined). The LSP server which resides in the mentioned sidecar does not need to have access to the analyzed file on filesystem.

[sergiuilie]

@tsmaeder I am opening the file inside Theia container but java LSP is running on another container, I will attach a gif to show that the /tmp folders are different and yet publish diagnostic is send over, that means didOpen notification was sent and TextDocumentItem contain the correct URI

[tsmaeder]

Hmh...but in our meeting, we checked that the file was present in the container that runs the language server, not the IDE container.

[tsmaeder]

BTW: jdt.ls sends errors for files that have not been opened, so we can't really deduce the sending of correct "documentOpened"-events from that fact.

[sergiuilie]

that's true, is the same behavior, same error

[tsmaeder]

Ok, I see it now. Unfortunately, the production versions of Che don't have source map info, so it's not trivial to analyze. The way I'm reproducing it is like so:

1. Open a Java-based workspace, open a Java file and make sure VS Code Java is running
2. Open a terminal in the theia ide container
3. `touch /tmp/Foo.java"
4. Open the file in the IDE using "File->Open"
5. Open the browser developer console
6. Do ctrl-space in the file
7. Observe: you get There are no document for file:///tmp/Foo.java in the browser console

[sergiuilie]

@tsmaeder the API used to open the document by Zowe extension is vscode.window.showTextDocument or vscode.window.openTextDocument depends on the condition, please check it out here
https://github.com/zowe/vscode-extension-for-zowe/blob/cbb5bf11652b70ae6da613e1448840f95689bf8f/src/extension.ts#L1540

[tsmaeder]

Ok, some time ago, we added code to support opening files that are present in plugin containers: https://github.com/eclipse/che-theia/blob/master/extensions/eclipse-che-theia-plugin-remote/src/node/che-content-aware-utils.ts

Basically, we override the URI for anything outside the /projects directory with a container-specific prefix. However, this prefix is not used in all requests, only for "definition" requests, it seems.
It's not a trivial fix. As a workaround I would recommend to download the file into a subfolder of /projects instead of /tmp.

[sergiuilie]

@tsmaeder understood, we are discussing this issue and see how is better to design our extension, one question: could you please let me know how I can debug che-theia?

[tsmaeder]

There is some doc in https://github.com/eclipse/che-theia/blob/master/CONTRIBUTING.md, but I'm not sure how up-to-date it is. Haven't had to debug lately.

I think what your extension is doing is reasonable, we just didn't expect that case.

[sergiuilie]

Thank you 😄

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.