Diagnostics is not showing in server.env file

[aparnamichael]

Following the update to LSP4IJ 0.4.0, one of our GHA UI test (GradleSingleModLSTest > testDiagnosticInServerEnv()) has been consistently failing on Windows. Upon investigation, we discovered that the issue has been occurring since the nightly build version 0.4.0-20240814-141029

LTI build with LSP4IJ version 0.4.0-20240814-141029(Aug 14) - https://github.com/aparnamichael/liberty-tools-intellij/actions/runs/11123067607

LTI build with LSP4IJ version 0.4.0-20240813-173701(Aug 13) - https://github.com/aparnamichael/liberty-tools-intellij/actions/runs/11123925619

LTI build with LSP4IJ version[0.4.0-20240815-013110(Aug 15) - https://github.com/aparnamichael/liberty-tools-intellij/actions/runs/11124525639

I created a fork of the lsp4ij repository and set up a branch (https://github.com/aparnamichael/lsp4ij/tree/lsp4ij-test), where I reverted a commit from August 14. After running an LTI build with these changes, the GHA UI test consistently succeeded.

LTI build ran using the LSP4IJ from https://github.com/aparnamichael/lsp4ij/tree/lsp4ij-test -> https://github.com/aparnamichael/liberty-tools-intellij/actions/runs/11346287359/job/31555011172

As a temporary fix for the UI test failure, we've implemented a workaround. Before checking for diagnostics, we close and reopen the server.env file, which triggers the diagnostics to appear and allows the test to pass successfully. Since the reverted commit in my lsp4ij branch is also related to file operations, could you please help us to identify the issue?

Also, it would be helpful if you could provide some details about the changes related to file listeners and operations in this commit .

[angelozerr]

Could you explain me what does your test?

Rename a file?

[anusreelakshmi934]

This test validates that the Language Server correctly detects and reports an invalid environment variable value in the server.env configuration file. It begins by setting up the necessary variables, including a configuration snippet, an incorrect value (NONE), and the expected error message. The test then activates the server.env tab in the IDE, ensuring it’s the focused file, and saves its current content to allow for restoration afterward.

It proceeds to insert the configuration snippet containing the incorrect value into server.env and hovers over the value, which should trigger a diagnostic pop-up. The hover message is then retrieved and compared to the expected error message to confirm accurate diagnostics.

In this case, when an incorrect value, 'NONE', is inserted, no diagnostics are shown.

Here’s a video of the failed test:

https://github.com/user-attachments/assets/457fea8a-c26a-4fc6-b226-9b447ca8f2b3

Ideally, diagnostics should be displayed when hovering over 'NONE'.

In our workaround, we first close the server.env file and then reopen it. After doing this, the diagnostic appears.

https://github.com/user-attachments/assets/1a8a15a5-3a07-493f-9861-8d8df9c9de2f

Here we can see the diagnostics appear after closing and opening the file.

[anusreelakshmi934]

We’re not entirely sure how this commit affects these tests. Could you provide more details regarding the changes made?

[angelozerr]

We’re not entirely sure how this commit affects these tests. Could you provide more details regarding the changes made?

I dont understand how this commit could impact the behavior.

If I understand your problem when you open the file the first time you have not an error range. If it that if you have no error range you will have no hover with the error message.

Could you please redo your demo and copy paste your lsp console. We need to check that you have a publishDiagnostic

[turkeylurkey]

@angelozerr Is it possible to get the lsp trace into a file? Then the test machine could dump it in a file and this could be collected after for analysis.

[angelozerr]

LSP4IJ doesn't manage that because we don't need it. But it exists listener to track that.

You could implement on your side a listener like https://github.com/redhat-developer/lsp4ij/blob/67f8e683d44f268fcdc28fb11a5c41cb253b1110/src/main/java/com/redhat/devtools/lsp4ij/console/explorer/LanguageServerExplorerLifecycleListener.java#L57 but please note this listener is not an API because it uses LanguageServerWrapper which is internal.

If you need this kind of listener, please create an issue and I will improve it to avoid using LanguageServerWrapper.

Please share your LSP trace and as I have tried to explain you here if you have not this LSP trace,you will not have error.

if you have this trace which comes from your language server but the error doesn'tappear, it is a bug from LSP4IJ. So please share your LSP trace.