I am using azure functions with the blob trigger and with the runtime 2.x. After the function being executed the runtime adds blob receipt into the location below (azure-webjob-hosts>blobreceipt>)
Is there any way to make runtime to use the same hostnameid in the path (in this case it's 8a76f42c1c01-2137340777)? Because if run function locally or publish new version of the code it would use different host identifier (like macbook-id).
The main problem is when I run func azure functionapp publish it will requeue all the existing blobs with new version of the code even when the new version has the same func name because it will use different host/func identifier to check for receipts.
I know that in runtime v1 you could add id into host.json. I dont see such option in runtime v2.
Edit:
Another thing. Just this morning I found out that my function run over all the blobs again. When I looked into blobreceipts I see that the hostid has changed and there are new bunch of receipts for the new host id. Host Id has changed even though I didnt do any deployments. How is that possible? I have also reported the bug on coretools about hostid getting changed on publish. https://github.com/Azure/azure-functions-core-tools/issues/1012
App name is altamente-prod-svc-shopify-background. But the host id is d7031c9b43fc-2137340777. I have removed all receipts to do more tests for now but you can see in logs that the func was initiated again this morning by itself over all my 7 blobs. There is just one function for now (and also WarmUp func which appeared automatically). I have created the linux func app via Azure portal with no functions and then just did publish with core tools from my mac.
There is a workaround now in the Azure Functions bug report that you linked to. Basically, set AzureFunctionsWebHost:hostid in the App settings to some explicit value. I'm using a self-hosted functions runtime and Kubernetes doesn't allow colons in environment variables, so I used the work-around of setting AzureFunctionsWebHost__hostid instead, which also works.
Related
I created a function and I am trying to deploy it from VS Code by clicking the Deploy to Function App.... The Deployment runs successfully based on the output log - Deployment successful but then when I go to the portal, the function is not listed under Functions.
What shall I do and what is the problem here?
When I debug in VS Code, I get this: No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
Unfortunatly I would not know if those steps don't work for uploading. The deployment finishes, and every single time it becomes visible in my portal. Uh, maybe there is a slight difference. The app service itself is pre-created via terraform. Just the uploading of the code I do via VSC.
As far as deletion goes:
Open the resource group, in the list lookup the App Service. Select the checkbox in front of it. Delete in the top nav bar of that pane.
Trying to delete it any other way will indeed give you the "Not found" error.
I've had the same 'issue', in my case it turns out that the issue was a bad entry in the requirements.txt
I had an incorrect line with 'io' and when it was present despite the deployment appearing to complete successfully in VS code, the function was not updated if it was previously deployed or not deployed if it wasn't resulting in the same 'no results' in the functions list.
Having other requirements such as 'numpy' or 'scipy' worked just fine.
It's an old thread but maybe it'll be helpful to whoever gets here in the future.
Even as of now, some changes I make in VS Code seem to take time to be immediately visible on the portal. I had a similar issue with resources, i.e. creating a resource from VS Code wouldn't make it immediately visible on Azure Portal. You can always go to Functions on the portal and click Refresh. Also try going to Advanced Tools, then Kudu and checking if your function can be found there.
One word of advice: if you publish your functions from VS Code, then work on that resource only from VS Code. You will find it reiterated all over Azure Functions docs that:
Publishing to an existing function app overwrites the content of that
app in Azure.
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 have deployed a javascript function app using VSTS Continuous Deployment and the function works but you can't see any of the code in the portal and the management screen looks seriously screwed up. By Function state it only has a grayed out garbage can instead of the grayed out enable/disalbe and the function key section is completely missing. The host keys section is empty even though I have host keys. This is frustrating because I can't set any function keys.
Similar to this one.
This probably means that your ARM template is incorrectly setting FUNCTIONS_EXTENSION_VERSION. Please make sure to set it to ~1. See this page for more info.
If your host keys fail to appear after you have deleted and redeployed your function app (I had this issue after upgrade from ~2 to ~3) then ensure all file shares and blob-containers (in used storage account) with the function app name are also deleted before trying redeploy. specifically the following containers:
azure-webjobs-hosts
azure-webjobs-secrets
Only by clearing these was I able to get a clean re-deploy - and host/app keys back again!
I have an azure function that I want to report what version of the code it is running. In other applications I am able to get this by running something of the nature:
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version
However I don't a) seem to have away of putting that data into the azure function (there is no assembly information button) or b) retrieving that information (the above code snippet always returns 1.0)
Is there a way (other than just putting in a configuration setting or private variable) to pull a standard version value from an Azure function via this mechanism?
I assume you are currently using .csx files from the Azure portal. If you instead switch to using Visual Studio and precompiled assemblies (which is generally recommended) the code you have above should work fine.
Specifically, use the following steps to change the version:
Right click on the Project and choose Properties
Go to 'Package'
Change the Package version
I have deployed my web job on production environment and suddenly blob trigger stops working(Looking into App Insight I know that blob trigger is not called).
If I debug the same code from the local machine then it triggers blob trigger.But stopped working in the production environment.
Always On is enabled.
Also, I have these containers are present
azure-jobs-host-archive,
azure-jobs-host-output,
azure-webjobs-dashboard,
Microsoft.Azure.WebJobs.Host,
Installed packages:-
Microsoft.Azure.Webjobs installed version is 2.0.0,
Microsoft.Azure.WebJobs.Host installed version is 2.0.0
According to your description, we couldn't directly find out why the blob trigger doesn't work. I suggest you could follow below way to troubleshoot by yourself.
If I debug the same code from the local machine then it triggers blob trigger.But stopped working in the production environment.
Since you found your webjob could work well in local, I guess maybe there are something wrong with the connection string config in your web app.
I suggest you could try to follow below way to change the production environment appsetting to set the storage connection string in it.
1.Open the portal and edit the appsetting as below.
2.Create another web app and publish the web job to it and run.
If these two ways all doesn't help you solve the error, I suggest you could post the log/error message and the details codes about the web job.
More details about how to find the log/error message, you could follow below way.