Command 'direnv: Reset and reload environment' resulted in an error

[paulhdk]

Hi!

My VS Code tasks aren't picking up my nix.shell, and I'm currently investigating why. direnv: reset and reload environment is currently giving me

Command 'direnv: Reset and reload environment' resulted in an error
Command 'direnv.reset' not found

Any pointers?

Many thanks,
Paul

[mkhl]

Any pointers?

Huh. Not really? The command is registered here: https://github.com/direnv/direnv-vscode/blob/main/src/extension.ts#L356
and that piece of code runs during extension activation…

[zeptonaut]

I'm running into the same issue -- given that the command was working days ago and the extension is installed and enabled, I can't figure out for the life of me why the command might not be found:

https://www.loom.com/share/c80c064be2464a758f678d31d77415f8

[zeptonaut]

A few more maybe-useful pieces of debugging information:

• I'm on the latest version of VS Code (1.85.1), but I updated trying to fix this error. The error also seemed to be happening on the previous version (which I'm not sure of the version number for).
• I'm on the latest version of the extension (released in September), but have definitely had this command work with the same version of the extension.
• direnv is at version 2.25.2 and is working to load the environment variables in the terminal: I mostly rely on the VS Code extension to inject the environment variables into run tasks
• None of the commands seem to be working, all giving the same error (command direnv.<command_name> not found)

I also tried uninstalling the extension, quitting VS Code, restarting VS Code, and reinstalling the extension without any success: I continue to get the same error.

[mkhl]

So bizzare. Thank you for the recording.
I looked for anything helpful in vscode issues and found two things that might be informative:

• Can you run Developer: Show Running Extensions (from the command palette) and look what it says direnv's status is?
• Can you run Developer: Toggle Developer Tools (from the command palette), switch to the Console view of the devtools, and see if there are any log messages related to direnv?

[zeptonaut]

Here's a screenshot of the running extensions:

Definitely seems... suspect that so many show up as "activating"?

In the developers tools, I see:

The extension host seems to oscillate between "responsive" and "unresponsive" states.

I did find this issue which is supposedly fixed. I am using the extension for a repository within a devcontainer (not running on GitHub codespaces, but rather locally), and that issue does seem to be related to devcontainers. But I also know that last week the extension was working fine 🤔

[mkhl]

Darn. That does look like a bug in vscode itself though, could you open another issue there?

(Make sure you open with the Cannot find module 'vscode' bit if you do, for "Command not found" issues they tend to just close and send you to the extensions' issues.)

Thanks for investigating!

[zeptonaut]

Yep - I'll do that. Sorry for the noise and thanks for helping to debug. With those logs, it definitely seems to be vscode related and I now see that other extensions that are hung in the "activating" state suffer the same fate when you try to run those commands.

[zeptonaut]

Just following up here for any future searchers: I managed to resolve the problem, which was not at all related to the direnv extension.

I discovered the answer by searching the VS Code issues for "cannot find module 'vscode'". That led me to this issue comment describing the problem and this comment describing the fix-- indeed, I did install datadog-agent on my devcontainer this morning, although I never in a million years would have guessed that was the culprit here.

As that issue suggests, datadog-agent manipulates the NodeJS module loading behavior in a way that conflicts with how VS Code loads extensions, effectively making those extensions unable to find the vscode module.

I fixed the issue (as described in that comment) with:

$ sudo apt-get remove --purge datadog-agent -y
$ rm -rf /opt/datadog
$ sudo nano /etc/ld.so.preload
# Edit ☝️ to remove the datadog-related line

After that, I needed to close down VS Code, wait for my devcontainer Docker containers to shut down, then reopen VS Code and the issue was resolved.

@gduquesnay was an absolute lifesaver there -- I have no idea how he managed to identify that fix, but I'm glad he shared it.