"Build failed for unknown reason" and entirety of mix.exs red underlined

[bmitc]

In Visual Studio Code (VSCode), ElixirLS consistently reports a problem with mix.exs, saying Build failed for unknown reason. See output log. This makes the entirety of mix.exs to be red underlined.

The issue causes problems with ElixirLS' autocomplete and intellisense features. This happens across many Elixir projects and repositories.

This has been reported before.

• ** (Mix.Error) Can't continue due to errors on dependencies JakeBecker/elixir-ls#71
  • I note that the workaround listed here sometimes works but frequently does not. The workaround is to set elixirLS.fetchDeps to false, close VSCode, run rm -rf deps _build .elixir_ls, run mix deps.get, and then reopen VSCode. However, as soon as you make any change to your dependencies, the problem often returns.
  • Someone reproduced this from scratch here.
• A seemingly related issue is: Fetching deps on save JakeBecker/vscode-elixir-ls#148
• https://elixirforum.com/t/elixir-vscode-autocomplete-dosent-work/29718
• Annoying red highlighting of the whole mix.exs vscode-elixir-ls#132

Environment

• Elixir & Erlang versions (elixir --version): Elixir 1.11.4 (compiled with Erlang/OTP 23)
• Operating system: macOS Catalina, version 10.15.7
• Editor or IDE name (e.g. Emacs/VSCode): VSCode
• Editor Plugin/LSP Client name: ElixirLS v0.8.0

Troubleshooting

• Restart your editor (which will restart ElixirLS) sometimes fixes issues
• Stop your editor, remove the entire .elixir_ls directory, then restart your editor
  • NOTE: This will cause you to have to re-run the dialyzer build for your project

If you're experiencing high CPU usage, it is most likely Dialyzer building the PLTs; after it's done the CPU usage should go back to normal. You could also disable Dialyzer in the settings.

Logs

1. If using a client other than VS Code, please try VSCode's "ElixirLS: Elixir support and debugger" extension. Does it reproduce your failure?
   Yes
2. Create a new Mix project with mix new empty, then open that project with VS Code and open an Elixir file. Is your issue reproducible on the empty project? If not, please publish a repo on Github that does reproduce it.
   This issue seems to occur with any Elixir project with dependencies.
3. Check the output log by opening View > Output and selecting "ElixirLS" in the dropdown. Please include any output that looks relevant. (If ElixirLS isn't in the dropdown, the server failed to launch.)
   I will need to check this output log on several repositories and can post a follow-up. However, this problem seems to be systemic with ElixirLS and not specific to any one repository.
4. Check the developer console by opening Help > Toggle Developer Tools and include any errors that look relevant.
   I haven't seen anything relevant there.

[bmitc]

For one project, here is the output log where ElixirLS fails. I tested and see that running mix deps.get and mix compile from the terminal doesn't generate this error.

==> dialyzex
Compiling 2 files (.ex)
[Warn  - 6:34:57 PM] warning: redefining module Mix.Tasks.Dialyzer.Clean (current version loaded from /Users/<username>/.vscode/extensions/jakebecker.elixir-ls-0.8.0/elixir-ls-release/dialyxir-1.1.0.ez/dialyxir-1.1.0/ebin/Elixir.Mix.Tasks.Dialyzer.Clean.beam)
  lib/mix/tasks/dialyzer.clean.ex:14

[Warn  - 6:34:57 PM] warning: redefining module Mix.Tasks.Dialyzer (current version loaded from /Users/<username>/.vscode/extensions/jakebecker.elixir-ls-0.8.0/elixir-ls-release/dialyxir-1.1.0.ez/dialyxir-1.1.0/ebin/Elixir.Mix.Tasks.Dialyzer.beam)
  lib/mix/tasks/dialyzer.ex:14


== Compilation error in file lib/mix/tasks/dialyzer.clean.ex ==
** (CompileError) lib/mix/tasks/dialyzer.clean.ex:29: cannot import Mix.Tasks.Dialyzer.otp_plt_name/0 because it is undefined or private
    (elixir 1.11.4) src/elixir_import.erl:64: :elixir_import.calculate/6
    (elixir 1.11.4) src/elixir_import.erl:18: :elixir_import.import/4
[Warn  - 6:34:57 PM] could not compile dependency :dialyzex, "mix compile" failed. You can recompile this dependency with "mix deps.compile dialyzex", update it with "mix deps.update dialyzex" or clean it with "mix deps.clean dialyzex"

[bmitc]

Any thoughts on this one? I'm still having this issue.

[j-burgos]

I've had this issue a couple of times, I'm not sure if these exact steps make it work but I've done this:

For context:
I have erlang and elixir installed using asdf.
I use the asdf plugin in my ~/.zshrc file

plugins=(git asdf)

The actual steps:

# Completely quit from VSCode GUI

# In your project's root folder:

# Remove deps and compiled files
rm -rf deps _build .elixir_ls

# Delete the extension included dialyxir
rm ~/extensions/jakebecker.elixir-ls-0.8.1/elixir-ls-release/dialyxir-1.1.0.ez

code .

Check in VSCode Output > ElixirLS. After some compilation and analysis it should show something like this:

[Info  - 8:17:23 PM] [ElixirLS Dialyzer] Analysis finished in 120467 milliseconds
[Info  - 8:17:23 PM] Dialyzer analysis is up to date
[Info  - 8:17:24 PM] [ElixirLS Dialyzer] Writing manifest...
[Info  - 8:17:25 PM] [ElixirLS Dialyzer] Done writing manifest in 1696 milliseconds.

[alexfariac]

I'm having a related problem where mix.exs is fully red highlighted with this error

(Mix.Error) Can't continue due to errors on dependencies
        (mix 1.11.3) lib/mix.ex:436: Mix.raise/1
        (mix 1.11.3) lib/mix/tasks/deps.loadpaths.ex:28: Mix.Tasks.Deps.Loadpaths.run/1
        (mix 1.11.3) lib/mix/task.ex:394: Mix.Task.run_task/3
        (mix 1.11.3) lib/mix/tasks/loadpaths.ex:37: Mix.Tasks.Loadpaths.run/1
        (mix 1.11.3) lib/mix/task.ex:394: Mix.Task.run_task/3
        (mix 1.11.3) lib/mix/tasks/compile.ex:113: Mix.Tasks.Compile.run/1
        (mix 1.11.3) lib/mix/task.ex:394: Mix.Task.run_task/3
        (language_server 0.8.2) lib/language_server/build.ex:200: ElixirLS.LanguageServer.Build.compile/0ElixirLS

yet I can run mix compile and run the application with no problems.
Any thoughts?

[ycherniavskyi]

@alexfariac I had resolved this issue by getting deps 😀 (and waiting for indexing) - mix deps.get.

[lukaszsamson]

Please head to Troubleshooting section in the README and use elixir forum for support

[bmitc]

Hi @lukaszsamson. Can you give more details why this is closed with a comment pointing to a troubleshooting section or forum?

The fact that there are various troubleshooting steps or workarounds (that sometimes work and sometimes don't) doesn't make this not a bug. By just closing this with no details or investigation, there is ambiguity.

If the ElixirLS team has decided that this is a will not fix scenario, then I think it's better to just plainly state that. There are several issues (closed without resolution or even comments from maintainers) and forum posts reporting this issue.

Lastly, if there's no way of preventing this issue from occurring, is it possible that ElixirLS could detect when the issue has occurred and automatically perform the troubleshooting steps itself?

[brianmay]

I am seeing this on several of my projects. I have tried various trouble shooting stuff (e.g. #597 (comment)) and it hasn't helped.

I really do think it is a bug in the plugin, it should be able to tell you what the actual error is. "Can't continue due to errors on dependencies" makes look very much like the real errors on the dependencies are not being shown.

From the command line there are no errors with the project.

This in turn makes the plugin version much unreliable, and I can't depend on it working.

[bmitc]

Hello! I am tagging @axelson, @NobbZ, @Trevoke, and @asummers since you four are listed as the people in the elixir-lsp organization. This issue was closed with no explanation.

In the original issue, I listed four separate reports of this issue, listed here again:

1. ** (Mix.Error) Can't continue due to errors on dependencies JakeBecker/elixir-ls#71
2. Fetching deps on save JakeBecker/vscode-elixir-ls#148
3. Annoying red highlighting of the whole mix.exs vscode-elixir-ls#132
4. https://elixirforum.com/t/elixir-vscode-autocomplete-dosent-work/29718

Note that in the original description comment, there is a link to a reproduction of this issue from scratch.

Additionally, this has been reported in the Elixir Forum in other posts:
5. https://elixirforum.com/t/vs-code-how-to-cross-reference-multiple-projects-not-in-umbrella/17705
6. https://elixirforum.com/t/elixirls-in-vscode/35391

I understand that people are busy and this is all volunteer and that anyone isn't being made to fix something. What I don't understand is why this issue is just closed without even addressing or discussing the issue.

A summary of the problem:

• ElixirLS constantly fails, underlines the entirety of mix.exs, and in VSCode, reports a "Problem" (i.e., error).
• There are some workarounds. However, there are several, and they do not always work.
• One such workaround is simply closing the editor and then reopening it. This does not always work, and even if it did, it is an annoyance to have to do so throughout the day.
• Sometimes suggestions of clearing out .elixir_ls are given. This is problematic because for large projects, it takes ElixirLS quite some time to rebuild everything (several minutes).
• In all cases of this particular issue, mix compile and mix test work fine even if mix.exs is underlined in red and reporting errors by ElixirLS.

So I think that this issue should remain open until fixed and not just closed. If the ElixirLS team or contributors do not ever want to fix it, then I think that should be clearly stated but the issue still left open for the case of someone coming along who wants to fix it.

The additional benefit of clear communication, rather than closing this and hoping it goes away and telling people to go somewhere else, is that people understand the status of ElixirLS and whether or not to look for other tools or look into contributing themselves. If an issue is buried by being closed, it prevents those things from happening.

[lukaszsamson]

My opinion on this is that it's a known issue with known (or at leas easily findable) workarounds. Even more, in the coming up version I added custom command to restart elixir-ls (elixir-lsp/vscode-elixir-ls#218). This is enough a reason to close it.
@bmitc if you have any concrete ideas on what can be improved and how, then please create separate workable items. PRs are always welcome.

[brianmay]

The work arounds often don't work. At least that has been my experience.

Also if it was a known issue, the issue itself should be documented somewhere. Documenting workarounds for a known issue isn't the same thing as documenting the issue - why it occurs, what triggers it, etc.

Later: Also forgot to say if it is a known issue, it should still be documented in an open bug report.

[lukaszsamson]

The work arounds often don't work. At least that has been my experience.

Sorry to hear that @brianmay but it's open source software that people work on in their free time. Would you like me or other community members to offer paid support?

the issue itself should be documented somewhere

It is documented in https://github.com/elixir-lsp/elixir-ls#troubleshooting, though I admit not very throughly. Care to improve it?

if it is a known issue, it should still be documented in an open bug report

That's disputable. Open bugs that are not workable only clutter the issues section. Elixir lang only keeps a handful of issues open and closes all other. Fortunately github has search function.

[brianmay]

Sorry to hear that @brianmay but it's open source software that people work on in their free time. Would you like me or other community members to offer paid support?

I use elixir for open source projects, as such I don't really have funds to offer for paid support. I am not getting any income from my Elixir work either.

That's disputable. Open bugs that are not workable only clutter the issues section. Elixir lang only keeps a handful of issues open and closes all other. Fortunately github has search function.

Yes, it definitely is the trend that maintainers will close bug reports that they "don't won't to look at" or "have been open too long". e.g. just recently I saw a maintainer of a project close a critical security bug, because fixing it would require a significant redesign. As a result people casually looking at the project would not know it suffered from a serious security issue. It is likely in the future that people will rediscover this security issue and open up new bug reports, which take the maintainers time to process and close.

Where I come from, bugs are only closed under set conditions. e.g. if it was fixed. Or it never was a bug. Or if it was a duplicate. That allows easy searching of bugs that are still open and have not been fixed yet. It also allows others to see what bugs have not been fixed and to offer help.

Also github has a "tags" feature. e.g. It is possible to mark a bug "wontfix" and then exclude "wontfix" bugs from the list of bugs. If this is not enough, the projects feature - with significant improvements in beta(*), offers other ways to sort through bugs, without having to close bug reports for bugs that have not been resolved.

But getting back on topic, we don't necessarily need a complete fix here. But maybe if we had some assistance to be able to debug what was going wrong. It might be some simple expectation about my project that isn't correct. Unfortunately the error message given is very generic, and doesn't tell us what is going wrong. I have no idea how to debug this.

e.g. is there some command we can use to demonstrate the problem outside visual code?

(*) at least last I checked it was still in beta.

[lukaszsamson]

Do anyone have a simple project that reproduces this reliably?

[brianmay]

@lukaszsamson I can point you to any one of my projects where this happens. e.g. https://github.com/brianmay/phone_db/

I have a sneaky suspicion that the problem might depend on some unknown aspect on my system, and if you tried to reproduce the problem it is going to work for you.

In fact, I just deleted the .elixir_ls directory and now I get a different error.

Failed to run 'elixir' command. ElixirLS will probably fail to launch. Logged PATH to Development Console.

But curiously, syntax highlighting seems to be working despite this error.

[bmitc]

As mentioned above, I could have debugged this more when I first reported it over a year ago, but I am no longer working at the company with the large Elixir codebases I reliably saw this in and do not currently use Elixir in my day job.

I have smaller personal codebases where I do not see this issue at present. Those codebases are highly curated in the sense that they are fully typespecced, have clean dependencies, and are compliant with Dialyzer and Credo, so I would expect those codebases to have less issues.

However, there are often flashes of it in that the entirety of mix.exs will be highlighted red but then soon gets unhighlighted, I suppose by ElixirLS doing some background work. Since I don't see a use case where the entirety of mix.exs being highlighted red makes sense, I suspect that this is related to the larger issue. I often see this happening in virtually every Elixir codebase when updating mix.exs.

[lukaszsamson]

@brianmay I cannot reproduce this on current master using your repo.

[lukaszsamson]

I'm convinced that big part of that errors was a duplicate of #120. This bug is fixed in 031bd0a which will be part of 0.12 release. I'm going to close the issue now. If anyone has a reliable repro steps, which is not a duplicate of #120 and is reproducible on current master then please open a new issue