Don't trust $PWD in Azure PowerShell Functions

The problem

So the other day I was working on an Azure Function based on the PowerShell stack. It was a simple function, but the script got rather large. So I refactored the script into several helper files and dot-sourced them in my run.ps1 file. Like so:

. "$PWD\helpers\some-helper-file.ps1"

Nothing special, and nothing I had not done before. However, when deploying this code to production it turned out that this did not always run correctly. The function could run fine for days, and then start failing for a couple of hours.

When I looked at the logs, it turned out that the Azure Function did not succeed in retrieving the helper file. The error message was:

EXCEPTION: The term 'C:\local\Temp\functions\standby\wwwroot\helpers\some-helper-file.ps1' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. 

The odd thing about this is the path: C:\local\Temp\functions\standby. That’s not at all what you would expect. As I was running an Azure Function on the consumption plan, I was assuming that it somehow had to do with cold starts and getting the files mounted in time. Or something like that… I’m no expert on the mechanics of Azure Functions. Running a premium plan was not an option so I started looking for other solutions. I believe I tried using relative paths as well, but I’m not sure. Anyway I got so stuck on this that I chose to revert my refactoring and just pasted all my PowerShell functions in the run.ps1 file. Not ideal, but it worked as a temporary solution to give me time to research it.

Same problem with the CLI

Fast forward a couple of weeks and I ran into the same problem again. This time I was working on an Azure PowerShell Function running the CLI for Microsoft 365. Using the setup I’ve documented here, I was updating the PATH variable to be able to use the m365 executable from a locally installed CLI for Microsoft 365 npm package:

# profile.ps1
$functionPath = "$PWD\node_modules\.bin" 
if ($Env:PATH.Contains($functionPath) -eq $false) {
    [System.Environment]::SetEnvironmentVariable('PATH',"$functionPath;$($Env:PATH)")
}

However, it just kept failing (randomly) with the same type of error message as before.

The reason

I was getting desperate, so I thought: Let’s checkout the different file path variables, and what they contain. So I added a couple of lines to my run.ps1 file and invoked the function.

And there it was in the logging in Application Insights, apparently $PWD was the culprit. It contained the wrong value, while the other variables like $PSScriptRoot contained the correct path. So I changed my code to use $PSScriptRoot instead of $PWD and the problem was solved.

Conclusion

It would seem to be a bug in the Azure Function runtime. A bug which I haven’t seen in other Azure PowerShell Functions that I’ve made. But I’m happy I found a workaround. I’ll check if I can get this to someone at Microsoft to get it fixed.

In the meanwhile, happy coding!