Bug 563489 - Problem markers are not always cleaned up when editor is closed in background
Summary: Problem markers are not always cleaned up when editor is closed in background
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: LSP4E (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 565670 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-22 11:37 EDT by Nitin Dahyabhai CLA
Modified: 2022-02-04 09:12 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nitin Dahyabhai CLA 2020-05-22 11:37:04 EDT
If I have a Generic Editor editor open behind another editor, the problem markers associated with the background generic editor are not cleaned up if I close it using the Close Others style options from the foreground editor's part tab.
Comment 1 Mickael Istria CLA 2020-05-23 10:52:48 EDT
That's an interesting issue to fix. I guess it can be that the LS integration fails to send the "reverted" document from filesystem when closing some dirty editor.
Do you have some steps to reproduce the issue?
Comment 2 Nitin Dahyabhai CLA 2020-07-18 23:25:02 EDT
Those are the steps.
Comment 3 Mickael Istria CLA 2020-07-21 11:30:54 EDT
It looks more like an issue with the LS themselves
"""
Diagnostics are “owned” by the server so it is the server’s responsibility to clear them if necessary. The following rule is used for VS Code servers that generate diagnostics:

    if a language is single file only (for example HTML) then diagnostics are cleared by the server when the file is closed.
    if a language has a project system (for example C#) diagnostics are not cleared when a file closes. When a project is opened all diagnostics for all files are recomputed (or read from a cache).
"""

so maybe the underlying LS didn't send a note to clear the markers?
Can you please share some steps to reproduce (which files are in play)?
Comment 4 Andrew Obuchowicz CLA 2020-07-29 16:09:29 EDT
*** Bug 565670 has been marked as a duplicate of this bug. ***
Comment 5 Mickael Istria CLA 2021-11-16 15:58:28 EST
Eclipse LSP4E is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/lsp4e/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest LSP4E snapshots (from https://download.eclipse.org/lsp4e/snapshots )
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present with snapshots:
* Create a new issue at https://github.com/eclipse/lsp4e/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed soon. Then the Bugzilla component for LSP4E will be archived and made read-only.