I met an issue when using Azure function.
I create a Azure Functions v1(.Net Framework) Http Trigger template in VS. But when I try to run it directly, exceptions thrown.
I am using latest version of VS(15.6.7) and Azure Functions and Web Job tools(15.0.40502.0).
When I run it first time, no prompt for installation of anything, it runs on 1.0.10 Azure Function CLI. After I restart my VS and try to run it again, VS asks to download 1.0.12.1 Function CLI. The download seems failed as I still see 1.0.10 on the tile of window. The exception remains all the time.
Any idea? It doesn't make sense since I just try to run a template.
The root cause is shown in your screenshot.
Starting Host(...,Version=1.0.11232.0)
It means your function Cli is 1.0.4 other than 1.0.10 actually, here's release note of 1.0.4. After tests, find that old version does cause this exception. This version issue roots in failing to download latest Azure Function Core Tools trough VS.
Update for official solution
Handle downloading problem of Azure Function Core Tools. Try the first option to download using VS again, if it still fails, use the second option, PS scripts.
Below is the original solution, similar to the first and third official option, just ignore it
More Details
Azure Functions and Web Jobs Tools is updated to 15.0.40502.0 recently and mechanism of using local function Cli is also changed. Release Notes.
Tools now consume a feed which keeps templates, build tools, and the runtime up to date whenever there is a change made in the service.
The first time we create an Azure function after this update, we can see the tip on the dialog Making sure all templates are up to date.... It means VS is downloading necessary cli and templates to this folder C:\Users\UserName\AppData\Local\AzureFunctionsTools.
After a while, we can see the tip changes as
If we don't wait the downloading to complete and create project directly, it will prompt that VS is downloading 1.0.12.1 Cli. And everything should work fine after that.
As for your problem, I reproduce it once due to slow network. It fails to download those files and tries to use old version cli downloaded by VS before.
Solution
I recommend you to delete AzureFunctionsTools folder and restart your VS to download it again.
If it still fails to download, you can download it manually.
You can find download link of cli, itemTemplates and projectTemplates in C:\Users\UserName\AppData\Local\AzureFunctionsTools\feed.json.
And the folder structure in C:\Users\UserName\AppData\Local\AzureFunctionsTools\Releases\1.0.12.1 is like this
cli
--func.exe
....
templates
--ItemTemplates.nupkg
--ProjectTemplates.nupkg
manifest.json
Content of manifest.json
{
"ReleaseName": "1.0.12.1",
"CliEntrypointPath":"C:\\Users\\UserName\\AppData\\Local\\AzureFunctionsTools\\Releases\\1.0.12.1\\cli\\func.exe",
"TemplatesDirectory": "C:\\Users\\UserName\\AppData\\Local\\AzureFunctionsTools\\Releases\\1.0.12.1\\templates",
"FunctionsExtensionVersion": "~1",
"SdkPackageVersion": "1.0.13"
}
Related
I have an App Engine Service, running on Google Cloud Platform.
I run an old version of my NodeJS application on it.
After having updated my code, I have run the following command: gcloud app deploy, in my GCP console, directly. It shows no error.
It says 'X files updated' and after that, I go on my application and the code is actually not updated.
I expect my code to be deployed and therefore, updated, after I run this command.
Why is this expectation not met?
Are you sure you are deploying to the same version? If you're deploying a different version, did you migrate traffic to this new version? To check this, login to console.cloud.google.com > App Engine > Versions
This will show you all the versions you currently have deployed and you can confirm which one(s) are serving traffic
You should also confirm that you actually have the 'updated' source code deployed. Following the link in bullet 1 above, you should see a column that says 'Diagnose' with 'TOOLS' under it. Click on the drop down and select 'source'. This will show you your source code. Confirm you have your updated code
If your files are static, they could be cached. You can try using cache bursting techniques (search Stackoverflow for this), or wait for some time and try again.
Hey I have deployed new azure function using Azure dev ops CI/CD. The function app has been deployed successfully and when I go to the main URL, it says your function app is running. I tried to test the end points("/save") using azure portal and the output is 404 Not found. The same results when I use POST man as well. Any help would be appreciated?
2020-11-21T11:30:45.769 [Error] The following 2 functions are in error:
Get: The function type name 'DocumentContextFunction.Functions.GetDocument'
is invalid.
Save: The function type name
'DocumentContextFunction.Functions.SaveDocument' is invalid.
I have fixed this by updating the value of the "FUNCTIONS_EXTENSION_VERSION" from 1 to 3. For some reason every time I deployed using Azure CI/CD, its value is set to 1, so I have to manually change it to be 3.
I encountered this error when my build targeted win-x64 whereas the Azure Function Platform was configured as 32 bit.
In my case I had a function created in portal. I then published a function via visual studio. After publishing the portal created function was 404 not found and I could not even delete the function from the portal.
Exact same code in a new function worked as expected.
This is not intuitive and were no indications in the portal that previous portal created functions would break.
This maybe buried somewhere in documentation but I would have expected a warning in azure before allowing other functions to break without code changes.
The author's question helped me understand where the problem was coming from. In my case, it was not about the CI/CD pipeline doing anything funny.
It was my IaC code which was not setting up the function app properly. It picks version ~1 by default but I had to set it to ~3.
My function apps were working until I included a new custom package with a later version of Microsoft.Extensions.Logging. My functions were using Microsoft.Extensions.Logging 2.1.1. The package had version 7.0.0, which is for Net7. It was incompatible with my Net6 projects.
When the package was added, the Microsoft.Extensions.Logging version in my project was updated to 7.0.0. The were no compile errors, but debugging showed that the assembly could not be loaded. This was causing the 404.
Changing the package version back to 2.1.1 corrected the problem.
This is what worked for me...
Note: I was getting 404 on my function which is a nodejs and inline editing on the browser.
Open your function.json and take a backup as we are going to change it.
See if in your function.json there are two different settings with "direction": "in"
For me there were two. I tried deleting but it keep coming back.
Next I went to 'Integrations' (on left menu) and opened my trigger and deleted it. This will recycle your trigger. And hope this works for you too.
I'm running an Azure function in Azure, the function gets triggered by a file being uploaded to blob storage container. The function detects the new blob (file) but then outputs the following message - Did not find any initialized language workers.
Setup:
Azure function using Python 3.6.8
Running on linux machine
Built and deployed using azure devops (for ci/cd capability)
Blob Trigger Function
I have run the code locally using the same blob storage container, the same configuration values and the local instance of the azure function works as expected.
The functions core purpose is to read in the .xml file uploaded into blob storage container and parse and transform the data in the xml to be stored as Json in cosmos db.
I expect the process to complete like on my local instance with my documents in cosmos db, but it looks like the function doesn't actually get to process anything due to the following error:
Did not find any initialized language workers
Troy Witthoeft's answer was almost certainly the right one at the time the question was asked, but this error message is very general. I've had this error recently on runtime 3.0.14287.0. I saw the error on many attempted invocations over about 1 hour, but before and after that everything worked fine with no intervention.
I worked with an Azure support engineer who gave some pointers that could be generally useful:
Python versions: if you have function runtime version ~3 set under the Configuration blade, then the platform may choose any of python versions 3.6, 3.7, or 3.8 to run your code. So you should test your code against all three of these versions. Or, as per that link's suggestion, create the function app using the --runtime-version switch to specify a specific python version.
Consumption plans: this error may be related to a consumption-priced app having idled off and taking a little longer to warm back up again. This depends, of course, on the usage pattern of the app. (I infer (but the Engineer didn't say this) that perhaps if the Azure datacenter my app is in happens to be quite busy when my app wants to restart, it might just have to wait for some resources to become available.). You could address this either by paying for an always-on function app, or by rigging some kind of heartbeat process to stop the app idling for too long. (Easiest with a HTTP trigger: probably just ping it?)
The Engineer was able to see a lower-level error message generated by the Azure platform, that wasn't available to me in Application Insights: ARM authentication token validation failed. This was raised in Microsoft.Azure.WebJobs.Script.WebHost.Security.Authentication.ArmAuthenticationHandler.HandleAuthenticate() at /src/azure-functions-host/src/WebJobs.Script.WebHost/Security/Authentication/Arm/ArmAuthenticationHandler.cs. There was a long stack trace with innermost exception being: System.Security.Cryptography.CryptographicException : Padding is invalid and cannot be removed.. Neither of us were able to make complete sense of this and I'm not clear whether the responsibility for this error lies within the HandleAuthenticate() call, or outside (invalid input token from... where?).
The last of these points may be some obscure bug within the Azure Functions Host codebase, or some other platform problem, or totally misleading and unrelated.
Same error but different technology, environment, and root cause.
Technology Net 5, target system windows. In my case, I was using dependency injection to add a few services, I was getting one parameter from the environment variables inside the .ConfigureServices() section, but when I deployed I forget to add the variable to the application settings in azure, because of that I was getting this weird error.
This is due to SDK version, I would suggest to deploy fresh function App in Azure and deploy your code there. 2 things to check :
Make sure your local function app SDK version matches with Azure function app.
Check python version both side.
This error is most likely github issue #4384. This bug was identified, and a fix was released mid-june 2020. Apps running on version 3.0.14063 or greater should be fine. List of versions is here.
You can use azure application insights to check your version. KUSTO Query the logs. The exception table, azure SDK column has your version.
If you are on the dedicated App Service plan, you may be able to "pull" the latest version from Microsoft by deleting and redeploying your app. If you are on consumption plan, then you may need to wait for this bugfix to rollout to all servers.
Took me a while to find the cause as well, but it was related to me installing a version of protobuf explicitly which conflicted with what was used by Azure Functions. Fair, there was a warning about that in the docs. How I found it: went to <your app name>.scm.azurewebsites.net/api/logstream and looked for any errors I could find.
I'm looking for a way to perform a hard reset on a NodeJS Azure Function that gets uploaded through VS Code? It's v2 of the Azure Functions.
Things I have tried
restarting the Azure Function via the portal
stopping/starting the Azure Function via the portal
removing the bin, obj, extensions.csproj and node_modules from the VS Code project and re-installing
The reason why I'm looking to do this is that I have updated a local package through npm install --save <my new module>, but it isn't running the latest package when I invoke my Azure Function after uploading with the updated package through VS Code. I have verified that the package was updated by reviewing the package.json file and the source in node_modules (on VS Code and in Kudu on the portal). My hypothesis is that by not changing the Azure Function's source code, the Azure Function doesn't reload with the new package, which seems like it could likely be a bug. I would prefer if I don't have to change the source every time I update the node_modules, which is why I'm looking for the reset.
Related except for C# - does't seem to make a difference with NodeJS
Any guidance is appreciated.
There're few things to try out here:
Please go to the Kudu website of your function app (url => https://{your-function-app-name}.scm.azurewebsites.net/) and navigate from "Debug console" menu >CMD/PowerShell, and:
Please check folder site>wwwroot>node_modules and make sure than expected module version is present there
If not then please make sure that the package-lock.json is pinning to a specific version of a module, and also please make sure that modules and their version in package.json and package-lock.json are as expected
Also, to reset the function app, you can add a test app settings {"testKey", "testValue"} which will cause your app to restart and pick up the new modules, and once the function picks up the new module then you can clean up this test app settings
I am building a Function App in C# with a compiled library. I deploy the code from the CLI and that's all fine.
Checking the file system with KUDU I can see all the files are updated, the *.dll is updated (the timestamp), but executing the function I get a result from an earlier build.
I execute the function locally from Visual Studio and everything is fine and outputs are as expected.
I can sometimes get the new build used by restarting the site from KUDU, but that's really not desired.
Any idea? I never had these issues when deploying through Github.
Where is your assembly deployed? If deploying the assembly to a folder outside of the actual function folder, please add that to the watchDirectories configuration in your host.json file.
You can find more information about that setting here.