bug: LSP willRenameFiles: "no such file" (src) error if WorkspaceEdit response part contained RenameFile part

[przepompownia]

At the moment I'm not able to quickly create repro with some mock response on workspace/willRenameFiles request so I'll try to describe it.

1. rename some file watched by LSP server attached to it
2. assume that the response contains RenameFile part

  documentChanges = { {
      kind = "rename",
      newUri = "file:///old",
      oldUri = "file:///new"
    } }

3. Observe Error applying actions: ENOENT: no such file or directory for the old path.

vim.lsp.util.apply_workspace_edit applied documentChanges (i.e. file has been renamed) - probably we should check if the old file exists.

Edit: I used the fresh master of Neovim, but the stable version shouldn't result in any different reproduction for usual cases.
Edit2: severity: minor - the error does not prevent from renaming.

[stevearc]

What LSP server is this? It sounds like it's behaving off-spec. If the client sends a "willRenameFiles" message to it, that means that the client is in the process of renaming these files. The server should not try to send back operations that will perform that rename.

[przepompownia]

@stevearc thank you for the answer. I will try to explain why I have a different opinion.

The server should not try to send back operations that will perform that rename.

The problem is that I didn't find such an assumption in the specification. On the other side I see the presence of the "RenameFile" part in the response (WorkspaceEdit) spec.

From https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_willRenameFiles:

The will rename files request is sent from the client to the server before files are actually renamed as long as the rename is triggered from within the client either by a user action or by applying a workspace edit.

Please keep in mind that my English is still poor. In my interpretation of this spec part, both your and my version are allowed.

The presence of the "RenameFile" part also seems good from a practical perspective. The response is then complete and the additional rename seems to be redundant. In particular by using the built-in Neovim library I can apply workspace edit directly (as Oil also does).

The background is my PR to phpactor/phpactor#2531. It adds the RenameFile part and fixes other things needed to rename.

[stevearc]

The will rename files request is sent from the client to the server before files are actually renamed as long as the rename is triggered from within the client either by a user action or by applying a workspace edit.

The way I would read this is that willRenameFiles can be triggered from either a user action (e.g. renaming a file in oil) or a workspace edit (e.g. a code action). The very next sentence is:

The request can return a WorkspaceEdit which will be applied to workspace before the files are renamed.

While it does not say it explicitly, this strongly suggests to me that the workspace edit should not include a "rename file" operation, because these edits will be applied "before the files are renamed". The next sentences:

Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep renames fast and reliable.

So the clients may end up dropping the workspace edits entirely in order to "keep renames fast and reliable". This is explicitly saying that the client is going to be performing the rename operation, regardless of any workspace edits from the server.

Another piece of evidence is that I have not seen any other LSP server respond to willRenameFiles with a workspace edit that renames those files.

[przepompownia]

This is explicitly saying that the client is going to be performing the rename operation, regardless of any workspace edits from the server.

If the client dropped entirely applying the response containing (or not) RenameFile part, it still can perform the rename directly (as oil tries to do).