Emacs ParseRequest error, no no such file when switching branches

[tsloughter]

Describe the bug

When I have a buffer open with, in the below example, otel_ctx.hrl, it then switch git branches to one without the file this error is given:

[ERROR elp_erlang_service] Erlang service crashed for: ParseRequest { options: [Includes(["/home/tristan/Devel/opentelemetry-erlang/_build/default/lib/eqwalizer_support", "/home/tristan/Devel/opentelemetry-erlang/apps", "/home/tristan/Devel/opentelemetry-erlang/_build/test/lib", "/home/tristan/Devel/opentelemetry-erlang/_build/default/lib", "/home/tristan/Devel/opentelemetry-erlang/apps/opentelemetry_api/include", "/home/tristan/Devel/opentelemetry-erlang/apps/opentelemetry_api/src", "/home/tristan/.cache/erlup/otps/OTP-26.1.2/dist/lib/erlang/lib"]), Macros([Atom(Atom { name: "TEST" })]), ParseTransforms([]), ElpMetadata(List(List { elements: [Tuple(Tuple { elements: [Atom(Atom { name: "eqwalizer_fixmes" }), List(List { elements: [] })] })] }))], path: "/home/tristan/Devel/opentelemetry-erlang/apps/opentelemetry_api/include/otel_ctx.hrl", format: OffsetEtf }, error: no such file or directory

To Reproduce**

Open a file, switch to a branch that the file doesn't exist.

Expected behavior

No crash of the elp_erlang_service

Actual behavior

elp_erlang_service crashes on a ParseRequest error.

Context

• ELP Version (output of elp version): elp 1.1.0+build-2024-02-16
• Editor used: Emacs 29.2.50

[robertoaloi]

@tsloughter Thanks for reporting.

This is a known issue where the file, as you realized, gets deleted on the file system but the client (Emacs in your case) still has an open version of the file in the editor and ELP tries to compute diagnostics for it by reading a non-existing version from the file system (in general we compute diagnostics from the source of truth - which is the version showed in the editor -, but there a couple of exceptions).

The error is harmless in the sense it does not affect the functioning of the language server, but it pollutes the logs un-necessarily. We also have some planned work where we pass the original text so we don't read it from the file system.

Will try to prioritize this.

[robertoaloi]

@tsloughter We decided to try and fix this in the "proper" way. This means we will have to introduce a bi-directional channel between ELP and the "Erlang Service" sidecar, so that the Erlang Service can operate on the source of truth for the file and not read from the file system. But this requires quite a bit of plumbing, so it will take a while before we can address this.