I keep getting this message whenever I try to debug an azure function in VS2017 and I can't figure out why.
Any input or assistance appreciated.
It appears to be looking for some kind of azure web jobs library:
This 'System.Threading.Tasks.TaskCanceledException' in System.Private.CoreLib.dll should be a first chance exception when function is triggered, no need to worry as it has been handled by function host.
If you don't see any red error info in function cli window (pop out when debugging) and your code is successfully executed, this should be an internal error.
Can't reproduce it on my side, hence just offer some suggestions based on my understanding.
Delete function sdk folder %userprofile%\.nuget\packages\microsoft.net.sdk.functions and install latest 1.0.14 package in your function project.
If it doesn't work, I recommend you to download VoidMethodInvoker.cs or JobHost.cs to detect the exception. Then ignore it by configuring Exception settings. Met an internal exception on queue trigger before.
Related
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 have been following the Microsoft azure developers online course and i have started an exercise on durable functions
First thing i had to do was to use Kudu to install the durable functions package via a package.json file
all details are in this link
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-create-portal
After this i had to create a new HTTP start function (details also in the above link) but the install does not complete successfully (see attached screen shot)
I have tried this a few times and no joy and unable to continue the course until i get this resolved
screen shot shows the errors and no matter how long i leave it it never completes
have also tried restarting the function and try again but no luck
screen shot - error installing HTTP start
ok i have now overcome this
Details of the fix are in this link
https://github.com/Azure/azure-functions-host/wiki/Updating-your-function-app-extensions
its important to stop the function otherwise you don't see the bin folder and the .csproj file you need to edit
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 created a queue trigger template of Azure function v2 in VS2017.
When I ran the project locally, the function runtime started successfully. But when I created a message in the queue, VS downloaded a JsonSerialization.cs file and pointed out the error.
Details of default Exception settings:
It's a template generated by VS, so there seems no code issue like what I have found in other posts.
What I have tried:
Publish the project to Azure, works.
Run the project with function core tool(Cli) installed by npm, also works.
I guess the problem is related to the function Cli used by VS. But its runtime version is 2.0.11651.0, same as the one installed by npm.
Have anyone met this before or got any idea? Thanks in advance.
This exception is internal and should be caught by the runtime. Feel free to ignore it in exception settings, and then everything should just work.
I am trying to deploy an application to the Azure Service Fabric using the release definition task. When it gets to the task to deploy the server is returning the following error:
The type initializer for 'Microsoft.ServiceFabric.Powershell.Constants' threw an exception
I checked the Endpoint configuration and it appears to be set up as it is supposed to be:
No Authentication (this is an internal text box)
Cluster endpoint: tcp://[service fabric server]:19000
It downloads the artifacts without a problem, but in deploy it searches for the paths for publish profile and application package and finds them. After it finds them it throws the error. I have tried replacing TCP in the endpoint with http, added and removed the :19000 as well and all I get is this error. I have been searching online with little success. Any help to this end is much appreciated.
John
After lots of researching trying every suggestion I could find, we decided try and connect to the machine via Powershell on the box and it too was returning this error. So we uninstalled the SDK and re-installed it and the connection could be made and the builds started to work. I don't know exactly why it failed, but apparently a re-install did the trick. It may have been a bad install, or it could have been a versioning problem. Either way, try a re-install first.