In SonarLint, the connected mode synchronizes the issue status with the project analyzed on SonarQube /SonarCloud. Currently, the matching is done with a hard comparison between local relative file paths and remote relative file paths.
The problem is that the definition of relative path varies:
In IntelliJ, it is possible to add files to the project that are not within the base directory of the project. This is done by adding a new 'content root', which could be any path. So in this case, 'relative path' would be the path of the file relative to its content root.
On top of that, the project in IntelliJ can be something different than the project in SonarQube. For example, the project in SonarQube might be added to an Intellij project as a module.
In SonarQube, the relative path is the path relative to the base directory of the module. Since IntelliJ only allows binding to root projects (and not to modules), it has a complicated logic to generate the path of files relative to the root project by fetching the hierarchy of the modules in a project and the paths relative to each other.
The current system is not robust enough and only works in cases where the structure of the project in Intellij perfectly matches the structure of the project in SonarQube.
Instead of comparing relative paths, we should put in place heuristics to match local files with remote files. One simple version would be to find the longest matching suffix.