Azure function is invoked but the code is never executed

[jeffhollan]

From @dixitsuneel on November 20, 2017 18:40

I can see in the monitoring log that the azure function is getting invoked.
But the code never receives the control for execution.

But if I hit the same http request to the function multiple times, then it starts working correctly after couple of tries.

I know that the control is never received by my code as the first line I have in my function app is context.log.info and that doesn't get executed.

What do we have to do to fix the issue?

Here's the screen shot where you can see multiple requests not completing and the logs section is empty for the selected request(2nd from the top)

Here's the screen shot of the first request which completed and you can see the log

I have also added global exception handling, just in case there is an exception then that method will terminate the context with an error.

Here's the code for the same
process.on('uncaughtException', function (err) {
context.log.error(err);
context.done(err);
});
There is no logging at all. Please help

Copied from original issue: Azure/Azure-Functions#601

[jeffhollan]

From @dixitsuneel on November 21, 2017 22:17

Is there any update? We need an answer on this to make sure that we are able to use azure functions in production correctly. We are blocked because of this issue.

[jeffhollan]

From @dbronk on November 22, 2017 12:9

It doesn't look like this issue has been looked at yet or assigned. This is a production blocker for us. How can we escalate this issue?

[jeffhollan]

Can you clarify which version of the runtime? There is an issue in v2 runtime for language extensions where cold-start may cause first invoke to fail - I can't find the issue to reference - but not sure if that applies here

[dixitsuneel]

We are using Node js version 6.5

[dixitsuneel]

Also, all of these are not cold starts. If you look at the timelines, they are executed within a couple of minutes duration. We have the function app on app service plan with always on and no timeout in the host.json file.

[jeffhollan]

Thanks that helps - looking into this

[paulbatum]

@christopheranderson can you please investigate this

[dixitsuneel]

Runtime version: 1.0.11388.0 (~1)

[TomMalow]

I have the exact same problem currently for one of our customers.

About 12 days ago half of our functions apps in our deployment slots stopped executing code but the functions are invoked based on the Monitor.

We are using Function App version 1.0 and the function is written with C# using Microsoft.NET.Sdk.Functions version 1.0.14 we have no configuration in the host.json file.

I have the following information one of our affected Time Triggered Functions that runs daily executed manually:
Invocation ID: ecc1c6d7-2ef9-49d2-b196-3bd8e34716ab
Timestamp: 2018-08-09T12:57:09.110
Region: North Europe

I have multiple functions that a triggered once a day. One example shows that the functions did work 12 days ago:

But all Time Triggered calls afterward succeeds but the code is not executed as there are not logging:

Additionally, as the initial post mention, manually triggering the function barely works. When triggering the function, the function returns 202 but nothing is triggered or is logged in the monitor. After multiple attempt the function is finally executed and everything works as it should:

However the time tiggere function the following day still failed to execute the code and log anything.

We have a couple of other functions with the same issue. But other time triggered functions stil works without any issues within the same time frame where the other fails:

The affected functions are the same across the slots but the issue is not present in the main Function App.

I have tried to deploy to the function along with restart and stopping/starting the functions as well. Neither thing works.

[paulbatum]

@TomMalow I looked at the logs for your app and I am fairly sure that you are hitting #2015 - basically your prod slot and your staging slot are competing to run the timer because they are ending up with the same host ID. Our logic calculates the host ID by using the app name and slot name but it truncates the name to 32 characters and your app name has exactly 32 characters without the slot name included.

My best recommendation at this point would be for you to recreate your app with a shorter name, such that the combination of app name + slot name is less than 32 characters.

One other possibility would be for you to explicitly set the host ID in host.json (see the id line here), and to make sure your production host.json has a different value to your staging host.json. You would need to be careful to maintain this every time you do a deployment or a swap. I see this as a relatively fragile solution which is why it was not my first recommendation.

If all of this sounds like a dumb limitation... I agree with you :/ Its a tricky issue for us to fix as it can be breaking in nature and there are multiple system components that have the same logic for calculating host ID.

[TomMalow]

Yep. That seems to have been the problem. Recreated one of the slots with a shorter name and the functions in the new slots are now able to run without any issue.

That is quite some limitation. Hopefully it will be better in 2.0. I will probably go and recreate the app with a better name to avoid the issue in the future. The current name does not leave much left for the slot name.

Thank you @paulbatum, for the quick respond. Sadly my solution does not seem to relate or solve this issue.