Azure function - “Did not find any initialized language workers”

26
votes

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

3
python-3.xazureazure-functions
I'm wondering if it has anything to do with FUNCTIONS_WORKER_RUNTIME setting. Can you check in your local.settings.json file for this setting and settings in Azure Portal? Ref: docs.microsoft.com/en-us/azure/azure-functions/…. – Gaurav Mantri
Yes I have set FUNCTIONS_WORKER_RUNTIME in both local.settings.json and in the Azure portal but still getting the error in the function in Azure portal (but not locally). – nathan shumoogum
I guess the language worker could have crashed. Try downloading the app content from the overview page and run it locally to see more detailed errors. – PramodValavala-MSFT
@nathanshumoogum How did you get this issue resolved? – RB17
@RB17 - Sorry for the slow reply but not working for for the company which this problem occurred for anymore and hence not working with Microsoft Azure. Hopefully some of the comments below will help you out – nathan shumoogum

3 Answers

1
votes

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 :

  1. Make sure your local function app SDK version matches with Azure function app.
  2. Check python version both side.
1
votes

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.

1
votes

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.