Auto Runtime Dependencies is broken

[chris-w-dev]

Describe the Bug with repro steps

PR #5225 seems to have caused some regression in main, resulting in a failure to install any dependencies successfully.

Scenario 1: Azure Functions Core Tools

Reproduction steps:

1. Go to the Logic App Standard extension settings and make sure Auto Runtime Dependencies Validation And Installation is checked
2. Close VSCode
3. Remove directory %UserProfile%\.azurelogicapps\dependencies\FuncCoreTools
4. Open a new window of VSCode, the Validating Runtime Dependency: Functions Runtime should start and download the dependency
5. Wait for the output window for Azure Logic Apps (Standard) to indicate Azure Logic Apps Standard Runtime Dependencies validation and installation completed successfully

Actual result:

Although the dependency installation process finished, folder %UserProfile%\.azurelogicapps\dependencies\FuncCoreTools is empty. The output messages also never show Successfullly downloaded FuncCoreTools dependency

This is caused by the fact that the temporary download directory is removed before the download is finished.

Output window messages:

FuncCoreTools Binaries: C:\Users\<username>\.azurelogicapps\dependencies\FuncCoreTools
Creating temporary folder... C:\Users\<username>\AppData\Local\Temp\.azurelogicapps\FuncCoreTools
Downloading dependency from: https://github.com/Azure/azure-functions-core-tools/releases/download/4.0.5455/Azure.Functions.Cli.win-x64.4.0.5455.zip
Removed C:\Users\<username>\AppData\Local\Temp\.azurelogicapps\FuncCoreTools
Azure Logic Apps Standard Runtime Dependencies validation and installation completed successfully.

Scenario 2: multiple .NET SDK versions

I've seen one case in which it tried to write to C:\Users<username>\AppData\Local\Temp\.azurelogicapps\DotNetSDK\DotNetSDK.ps1, but failed to do so because the file was locked. This could indicate some kind of race condition, as it tries to install both .NET 6 and .NET 8 at the same time. I haven't been able to reproduce it afterwards, so I don't have the output logs for it anymore.

Reproduction steps:

1. Fix scenario 1.
2. Go to the Logic App Standard extension settings and make sure Auto Runtime Dependencies Validation And Installation is checked
3. Close VSCode
4. Remove directory %UserProfile%\.azurelogicapps\dependencies\DotNetSDK
5. Open a new window of VSCode, the Validating Runtime Dependency should start and download the dependencies

What type of Logic App Is this happening in?

Standard (VSCode)

Are you using new designer or old designer

New Designer

Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg

Yes

Workflow JSON

No response

Screenshots or Videos

No response

Browser

N/A

Additional context

No response

[ccastrotrejo]

Hey @chris-w-dev thank you so much for raising this issue. Which version on the vscode extension are you using? The mentioned PR is just in versions 4.50 and above. If you are using those or compiling the main branch it makes sense that the PR is messing up the functionality. I will triage it with the team anyways.

[chris-w-dev]

Hi @ccastrotrejo. I ran into this while I was testing #5263 on today's main branch (commit 1c721bd), so I guess sort of 4.53. Had to make sure it worked.

[ccastrotrejo]

Alright, makes sense then. Thanks!

[mireedmsft]

This is interesting... this codepath has always been there (deleting the temp directory when a download fails), but previously that download failure would also cause activation to fail outright (which would then succeed on the next restart). My change allows activation to continue in this case.

This is an interesting use case, I need to try a repro and decide what to do here.

In the mean time I will revert that change to unblock the deploy.

[mireedmsft]

The change has been reverted in main now: https://github.com/Azure/LogicAppsUX/pull/5269

I'll spend some cycles to figure out what I want to do here then send a new PR as I have free time.

[chris-w-dev]

I noticed this finally block fired first and this error handler right after. Which makes sense, since downloadPromise.then is not awaited. Also, the exception in that error handler never showed up anywhere except in the debugger:

rejected promise not handled within 1 second: Error: ENOENT: no such file or directory, open 'C:\Users\<username>\AppData\Local\Temp\.azurelogicapps\FuncCoreTools\FuncCoreTools.zip'
stack trace: Error: ENOENT: no such file or directory, open 'C:\Users\<username>\AppData\Local\Temp\.azurelogicapps\FuncCoreTools\FuncCoreTools.zip'