Function App Cold Starts Results in 404 Before Reaching Function

[tkutcher]

Recently, for several of our Linux Consumption Plan Function Apps, requests that are made after a quiet period (i.e. what presumably would be a cold start), often result in an immediate 404. Immediate subsequent requests also respond with the 404 nginx page. Then after several seconds (i.e. no longer cold), the function behaves as normal and reaches the actual function app.

This appears to be similar behavior as was described in #5086, however it seems it may be occurring again. I also noticed this recent question on stackoverflow which I am assuming is related.

Investigative information

Here is just one of the scenarios, but this has been happening for 3+ of our function apps (all linux consumption). Does not happen all of the time, but often enough that we can't take apps to production.

• Function App version: 3.0.15828.0
• Invocation ID (of the invocation that actually reached the function, the 404s don't reach the function): 3c7651ca-4560-47c5-905c-e2e6a2ca1c7e
• Timestamp: 2021-06-01T15:29:06Z
• Region: East US

I have also noticed that even going to the root domain of the function app (that is supposed to show the "Your function is up and running page") does not show that page and instead shows the page as if the function is down for cold starts. Unsure if that is typical or not.

Expected behavior

Response from my function code, that may take a little longer (few seconds) since it is a cold start.

Actual behavior

Immediate 404 response, no invocation made to my function.

Related information

• Python
• HTTP bindings
• Linux standard consumption plan

[v-bbalaiagar]

Hi @tkutcher, Thank you for reaching out to us, checking internally on this issue.

[mikecole]

I am running into this same issue on a Windows consumption plan, with HTTP requests returning 404 or 503. If I hit the endpoint a few times in PostMan, it eventually succeeds, but I would expect a longer wait time for a cold start rather than a 404/503. Will watch this issue and hopefully the fix applies to my situation as well.

[mikecole]

@tkutcher Did you get a resolution from this issue?

[pragnagopa]

Tagging @balag0 @yojagad - fyi for linux consumption

[tkutcher]

@tkutcher Did you get a resolution from this issue?

@mikecole not yet - behavior still occurring as of this morning.

[mikecole]

@tkutcher Based on research I did yesterday it appears we aren't the only ones. I set up an uptime robot on one of my HTTP trigger endpoints and saw more downtime than I expected.

[v-bbalaiagar]

Hi @mikecole, Can you open a separate issue with the details as it looks like you are running on the different plan.

[yojagad]

For linux consumption, this is a known issue (for python 3.9) and the fix for that will be rolled out as part of the next release
Azure/azure-functions-python-worker#854

As a workaround until this is rolled out, can you please add the following app setting and value and see if that works for you ?

Setting Name: PYTHON_ISOLATE_WORKER_DEPENDENCIES
Setting Value: 0

[tkutcher]

From what I can tell with this workaround the behavior is not occurring for apps that it previously was occurring (I am now realizing that all the apps it occurred for were python 3.9). So this workaround works for me until the next release.

Feel free to close this issue.

[pragnagopa]

Thanks for confirming @tkutcher ! Closing this issue.