Salesforce CLI Integration ignoring input

[bengelj]

Summary

Begining with the update to Salesforce Extension Pack (Expanded) v59.16.0 on 1 February 2024, multiple commands run within the VS Code IDE with right click in the Explorer pane, click on the status bar or execution form the Command Palette (CTRL-SHIFT-P) stopped working.

Equivalent CLI commands still work.

Specifically, this includes SFDX: Set a Default Org (either from the plug icon -- if it is present-- or the Command Palette), and SFDX: Retrieve Source From Org (right click in the project explorer). Other commands may also be affected.

This was a project connected to a (developer) sandbox. I do not know if that's relevant or if a scratch org would have the same problem.

sf org list shows the Dev Hub (prod) and sandbox (devtest1) both connected. sf org login web ran successfully

Steps To Reproduce:

1. Open a project connected to a sandbox org
2. Confirm that the Dev Hub and sandbox org are connected (sf org list)
3. If the default org is not shown in the status bar, type CTRL-SHIFT-P and select SFDX: Set a Default Org
4. Open any component folder (classes, flows, etc) that contains a component that exists in the org
5. Right click the component's metadata file, and select SFDX: Retrieve Source From Org
6. Alternatively, select a component from the Org Browser and click the download icon

Expected result

Default org is set. New version of metadata is retieved.

Actual result

Both commands ran for 45 minutes with no results, no errors, just spinning away doing nothing detectable.

Additional information

I was able to set the default org in the CLI with sfdx force:config:set target-org devtest1 (this command is probably deprecated, but it still works and doesn't offer an alternative sf command, nor does the documentation give an alternative for setting a default org form the CLI.) I was able to retrieve the components I was working on using sf project retrieve start --metadata Flow:Find_or_Create_Participant sf project retrieve start --metadata Permissionset:NCRAN_External_Objects

The fact that the CLI still works, but the extension does not, is what makes me think the problem is in the SFDX CLI Integration extension, but what I can't know is if there's a bug in the extension, or if there is something in my setup that it doesn't like. I can say that the day before the latest update, I didn't have this problem, and was working on the same flow.

At one point yesterday, this message was shown on the product page in VS Code: Salesforce CLI Integration v59.16.0 This extension has reported 2 uncaught errors Cannot access 'r' before initialization Cannot access 'r' before initialization

Feel free to attach a screenshot. What's not visible in the screenshot is the CLI command to set the default org. That was on the Terminal tab.

More details in this community post (which has no replies except my own as more information surfaced) https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007X8zHESAZ

Salesforce Extension Version in VS Code: Salesforce Extension Pack (Expanded) v59.16.0 Salesforce CLI Integration Published 2017-09-21, 12:30:15 Last released 2024-01-31, 20:48:49 Last updated 2024-02-01, 08:08:18 Identifier salesforce.salesforcedx-vscode-core

SFDX CLI Version: $ sf version --verbose --json { "architecture": "win32-x86", "cliVersion": "@salesforce/cli/2.26.10", "nodeVersion": "node-v20.10.0", "osVersion": "Windows_NT 10.0.19045", "rootPath": "C:\Users\bengelj\AppData\Local\sf\client\2.26.10-b796e35", "shell": "C:\Program Files\Git\usr\bin\bash.exe", "pluginVersions": [ "@oclif/plugin-autocomplete 3.0.5 (core)", "@oclif/plugin-commands 3.1.1 (core)", "@oclif/plugin-help 6.0.12 (core)", "@oclif/plugin-not-found 3.0.9 (core)", "@oclif/plugin-plugins 4.1.21 (core)", "@oclif/plugin-search 1.0.12 (core)", "@oclif/plugin-update 4.1.8 (core)", "@oclif/plugin-version 2.0.11 (core)", "@oclif/plugin-warn-if-update-available 3.0.9 (core)", "@oclif/plugin-which 3.0.15 (core)", "@salesforce/cli 2.26.10 (core)", "apex 3.0.20 (core)", "auth 3.3.3 (core)", "data 3.0.17 (core)", "deploy-retrieve 3.2.6 (core)", "info 3.0.18 (core)", "limits 3.1.5 (core)", "marketplace 1.0.18 (core)", "org 3.3.8 (core)", "packaging 2.1.0 (user)", "schema 3.1.0 (core)", "settings 2.0.19 (core)", "sobject 1.1.3 (core)", "source 3.1.6 (core)", "telemetry 3.1.10 (core)", "templates 56.0.11 (core)", "trust 3.3.2 (core)", "user 3.2.4 (core)" ] }

OS and version: Edition: Windows 10 Enterprise Version: 22H2 Installed on: 3/3/2022 OS Build: 19045.3930

VS Code version: Version: 1.86.0 (user setup) Commit: 05047486b6df5eb8d44b2ecd70ea3bdf775fd937 Date: 2024-01-31T10:28:19.990Z Electron: 27.2.3 ElectronBuildId: 26495564 Chromium: 118.0.5993.159 Node.js: 18.17.1 V8: 11.8.172.18-electron.0 OS: Windows_NT x64 10.0.19045

[bengelj]

@daphne-sfdc I've not only restarted, I've powered down (which I do at the end of the day anyway) and the error persisted on both sides of the restart. I also had a restart for a Windows update, but I think that was before this weirdness began.

And I saw a lot of conversation online about phantom processes hanging on and how to kill them ones that were hanging up port 1717, but using the directions usually provided for Windows (kill Node.exe in Task manager) was a non-starter, because there was no such process running.

The corrupted HTTP request method is like a big flashing red light, but I don't know what it's flashing on. I'd guess it's a config file or a setting, but where that might be I have no clue.

Much as I hate to do it, I may have to try uninstalling the CLI and reinstalling it it again.

[daphne-sfdc]

Hi @bengelj, I just learned from CLI Team that this is an incompatibility between the CLI and Chromedriver v123. I also see the issue now after my Google Chrome updated itself from v122 to v123. The workaround here is to downgrade your Google Chrome version to one that uses Chromedriver v122 or below, or use a different browser. Sorry for the inconvenience!

[bengelj]

@daphne-sfdc That tracks with the Chrome update that I had run automatically yesterday. Our browsers are managed so I can't roll Chrome back, but I can switch the default to one of the others. The CLI auth commands with the --broswer option in both Firefox and edge both worked exactly as advertised, so Edge doesn't have enough Chrome in its DNA to be affected by the bug (or it just hasn't been up dated with that "feature" yet). I'm back on v60.5.0 for the SFDX extensions, so now I'm back to only having the problem(s) I had before.

[daphne-sfdc]

@bengelj Now that you're back to having only the problems that you had before, can you run SFDX: Authorize an Org and send us the contents of Developer: Toggle Developer Tools? We would like to see what our additional console.log() statements say about your issue.

[bengelj]

Well the good news is that Authorize an Org appears to (a) work, and (b) set the default correctly -- which makes me wonder if there wasn't a Chrome issue all along, because it was getting through the authentication portion of the programme fine before, but failing to set the newly authorized org as the default.

The bad news is that attempting to retrieve source form org with a right click in the project explorer still fails, but there should be something in the log about that, because when I cancelled the command after ~5 minutes, everything in red shown here immediately popped up in the console. including our old friend "Cannot access 'r' before initialization"

I finished up by trying to set the default org using the org name in the status bar, which just sat there doing nothing until I saved the log and quit VS Code. There's no Cancel button for that one, so there may not be anything in the log about that. The output tab was just showing that the command started, but nothing more. There's a little bit that looks like it might be related to what I was doing when I selected which org to set as default (devtest1), but I'm just basing that on what looks like a call to something called orgPicker. But there could be something useful there. vscode-app-1711055749606.log

Is this console going to be part of the official release in 60.5? Because it looks like it could be wicked useful.

[daphne-sfdc]

@bengelj I did a search on the TypeError: cb.apply is not a function error that's showing up in your log file. It looks like that might be a Node issue - can you try uninstalling and reinstalling Node? (No need to update to the latest version unless you want to, just uninstall and reinstall.)

No, the console.log() statements not going to be in our v60.5.1 release going out tomorrow 😆 They're just extra logging that we specifically added into the code for the purpose of diagnosing your issue - we add these custom log statements where users face issues and generate custom VSIXs for each individual use case. But we do plan on making improvements to our telemetry in general in the future.

[bengelj]

@daphne-sfdc That's too bad. Uninstalling and updating Node (20.11.1) doesn't appear to have had any discernible effect, but while I was doing that SFDX 60.5.1 installed itself, so I'm going to have to revert it from the VSIX's to get you anything more in the way of log info.

Okay, that was weird. I thought I rolled back the extensions, but when I reloaded the window, they updated to 60.5.1 again.

So reinstalling form the VSIX's without uninstalling appears to have worked... everything says it's back on 60.5.0. Tried to set the default org from the command palette, and ended up in the same place as before.

There's the old cb.apply is not a function error again. I'm wondering if we were in the right church, wrong pew with the Node installation. Could it be one of the node modules that's causing it to hack up a hairball? Anyway, here are the new log files. I didn't attempt a retrieve, but if you think ti would be illuminating, I will.

vscode-app-1711133636170.log sf-2024-03-22.log

[daphne-sfdc]

Can you try this solution? https://github.com/nodejs/help/issues/2874#issuecomment-663661148

It's possible that it's an npm issue and not a Node issue.

[bengelj]

@daphne-sfdc Pardon the stream of consciousness, and irritability that follows, but I think something in this finally did the trick. I was taking ontes as aI went, and they may reflect some annoyance. But thanks for all your effort, I DO appreciate it, and the annoying bits were actually not caused by the extension pack (or I don't think they were anyway). Some of it may not even be Salesforce at all (I suspect Azure). But assuming I didn't destroy my laptop in the process, I think we have SFDX working now. And I'm going to go make dinner and watch the hockey game and try to forget the frustration until Monday.

I can probably do Option 1, if I have to go to Option 2, it'll probably be Monday because it'll require getting another temp admin password to reinstall.

Or maybe not. I was able to remove the ~/AppData/Roaming/npm directory, but when I got to the next step $ npm clean cache --force npm WARN using --force Recommended protections disabled. Unknown command: "clean"

Ah... that's because it's npm cache clean, not npm clean cache.

Okay, that caused an error in a different extension, but I'm not sure it's relevant to this. But something was definitely bothered by that folder being missing.

_An error occurred while Azure-Node-Essentials was installing dependencies. Error: Command failed: npm ls --depth=0 -g npm ERR! code ENOENT npm ERR! syscall lstat npm ERR! path C:\Users\bengelj\AppData\Roaming\npm npm ERR! errno -4058 npm ERR! enoent ENOENT: no such file or directory, lstat 'C:\Users\bengelj\AppData\Roaming\npm' npm ERR! enoent This is related to npm not being able to find a file. npm ERR! enoent npm ERR! A complete log of this run can be found in: C:\Users\bengelj\AppData\Local\npm-cache_logs\2024-03-22T20_54_47884Z-debug-0.log

But the error "cb.apply is not a function" is coming form VS Code's extension handler. Sorry, mainThreadExtensionService.ts. And it appears that Azure Node Essentials might be what's throwing that error to begin with:

[azuresdkteam.azurenodeessentials]cb.apply is not a function $onExtensionRuntimeError @ mainThreadExtensionService.ts:81 S @ rpcProtocol.ts:458 Q @ rpcProtocol.ts:443 M @ rpcProtocol.ts:373 L @ rpcProtocol.ts:299 (anonymous) @ rpcProtocol.ts:161 y @ event.ts:1127 fire @ event.ts:1158 fire @ ipc.net.ts:650 V.onmessage @ localProcessExtensionHost.ts:376 mainThreadExtensionService.ts:82 TypeError: cb.apply is not a function at c:\Users\bengelj.vscode\extensions\azuresdkteam.azurenodeessentials-0.2.6\node_modules\npm\node_modules\graceful-fs\polyfills.js:287:18 at FSReqCallback.oncomplete (node:fs:213:5)

I uninstalled Azure Node Essentials and reloaded the window, and that appears to have got rid of the cb.apply error (though it's hard to tell) and it also seems to have fixed the set default org problem. AND the Retrieve source from org issue. At least in the project explorer. I can switch back to my original default org using th estatus bar too. Now I'll see if I can retrieve form the org browser (if it ever refreshes).

Okay, Org browser is still having a snit, but it hasn't actually failed, it's just taking forever to refresh the view in the new default org. Hmm... maybe the authentication has expired?

Uh oh... Starting SFDX: Authorize an Org

17:16:50.256 sfdx org:login:web --alias devtest1 --instance-url https://test.salesforce.com --set-default 'sfdx' is not recognized as an internal or external command, operable program or batch file. 17:16:50.374 sfdx org:login:web --alias devtest1 --instance-url https://test.salesforce.com --set-default Salesforce CLI is not installed. Install it from https://developer.salesforce.com/tools/sfdxcli

I installed the CLI with npm because the installer kept giving me a fit. Let's see if I can get past that -- hopefully my temporary password hasn't expired yet.

First, let's see if we can uninstall the version installed with npm. Looks like that's working (so far) okay, looking at the screen it looks like it installed it, but sf version gives me sf command not found, so I'm guessing it was successful. So lets' try the Windows x64 installer (I think that's the one I need anyway).

Okay, it wants an install location... NOT Program Files... I need to be able to update it. How about ~/AppData? It seems okay with that. Guess we'll find out. It installed...

OKay, apparently that's not in my $PATH. But oddly enough both of these are, and I was always able to update before... Hmm... /c/Program Files/sfdx/bin /c/Program Files (x86)/sf/bin But neither of these folders exist.

Alright... lets uninstall from where we put it, and hope we don't shoot ourselves in the foot putting it under Program Files...

Oh dear. this looks very bad. I'm seeing file names going by that have nbothing to do with the salesforc eCLI... like it's deleteing the entire AppDat folder. And it just deleted the TypeScript folder from AppData Local and now it's working on Mozilla. SO maybe I should hurry up and post this and hope I'm still here when okay, I managed to kill it, but who knows what state it left things in.

Well... let's see what happens when we install it to Program Files. What've I got to lose, right?

Okay, it's in Program Files/sf but I still get command not found. Guess that answers the previous question. Oh... that's probably because the PATH variable is looking for it in Program Files (x986)... Great. If I had any sense I'd quit while I'm ahead, but I'm kinda scared of running the uninstaller in it's present location. Looks like AppData being nuked (partially anyway) is survivable, but Program Files I'm not so sure about.

Okay, I seem to have survived the uninstall, but now I'm wondering if I used the wrong installer. There's an x64 and an x86 and while I'd expect x64 to be the one I need, there's an sf directory in Program Files x86 in my path, and there must've been something in there at some point else why would it be there? I suspect this is why I used npm to install it before.

Okay, looks like third time's the charm, I can execute sf version... and sf update. With the x86 installer. Go figure. You would think that when there are two options, there's be something in the documentation to let you know how to pick the one you need. But no. At least not anywhere obvious. If it were me, I'd put it on the download page. Or in the "Install Salesforce CLI" article. But while everyone seems to be eager to offer a short history of the entire evolution of the product, nobody felt it necessary to include that detail.

But back to the issue at hand, now that I have the CLI successfully installed, I can retrieve from the org browser, which was the thing I was trying to figurine out.

So apparently the thing to do was uninstall Azure Node Essentials, install and uninstall the CLI 3 times (hopefully not wreck my laptop in the process), and clean pout an npm folder...

Seems excessive, but it appears to have worked. I think.

[daphne-sfdc]

Hi @bengelj, I'm very happy to hear that your environment issues are now resolved! That was a complicated set of steps that you did - glad that you didn't break your computer 😂

As for the x86 CLI that you installed... I do believe that your case is the exception and not the norm. Your computer is a 64-bit Windows machine, as you pointed out in your initial report - thus, you made the right choice to try the x64 version of the CLI installer first. It's weird that the x86 version worked for you and not the x64 version - but we really shouldn't try to fix something that is no longer broken.

I'm going to close this Github issue now. If you run into any more problems with your setup, feel free to reopen it.

[daphne-sfdc]

@bengelj One more thing - Can you open up a new Command Prompt and run wmic os get osarchitecture? Given the fact that you are using a 32-bit CLI and a 64-bit VSCode, our team would like to confirm with you about the type of machine you are using. (We think it's likely 64-bit but would really like a sanity check because of your unusual configuration!)

You should get something like this when you run the command:

[bengelj]

@daphne-sfdc Your suspicions are correct, $ wmic os get osarchitecture OSArchitecture
64-bit

But I should add that I tried installing the Windows x64 CLI, and ended up with the x86 version (32-bit) because nothing I did with the PATH environment variable made sf.exe "visible" and by that time I was about 2 clicks form homicidal, and decided if that wasn't working do the other thing. Oddly enough, /c/Program Files (x86)/sf/bin was already in my PATH, so I must've had the x86 version installed at some point -- or the installer set both paths (/c/Program Files/sfdx/bin is also in the PATH variable). But by the time I was done, I'd made so many changes in the course of last week, I couldn't' tell you which of them had any effect and which were just no-ops. Updating Java to 17 or Node to v.20 might have had an impact -- or not. Reinstalling VS Code? Who knows? getting that rogue npm directory out of AppData/Roaming probably had an impact, but I suspect it was uninstalling the Azure Node Essentials extension that finally did the trick. But I'm not gonna reinstall it to test the theory.

It appears I lost some settings, and by bookmarks in Chrome (which I'd imported to Firefox when I switched default browsers, but apparently some of them didn't make the translation), and for some weird reason the desktop icon for Edge -- though the browser itself seems to be working well enough. So unless something I haven't seen yet comes up and cripples me I'll just wait until I'm due to have this laptop replaced or upgraded to Win 11. 'Cos I'm getting way too old for this sh...tuff.

[daphne-sfdc]

@bengelj Thank you for the confirmation that it's a 64-bit computer. Sorry about the loss of your settings and bookmarks, and good luck until you get your laptop replacement/upgrade!