[Bug] Bug Title Here

[NoobsDeSroobs]

Expected Behavior

os.getenv("erp_LANDING_STORE_CONNECTION_STRING").strip() returns the environment variable I have set under App Settings.

Actual Behavior

os.getenv("erp_LANDING_STORE_CONNECTION_STRING").strip() causes an Error.

Steps to Reproduce

As this works with another function app in my RG there is no guarantee you can reproduce it, but:
Deploy a FlexConsumption app (I used terraform and Visual Studio Code for the deployment using 'func azure functionapp publish')
Print the environment variables and see that the environment variable does not exist.

Relevant code being tried

@my_bp.service_bus_queue_trigger(arg_name="inputMessage", queue_name=f"{azure_environment}-test-queue", connection="SERVICE_BUS_CONNECTION_STRING")

def env_print_func(inputMessage: func.ServiceBusMessage):
    os.getenv("erp_LANDING_STORE_CONNECTION_STRING").strip()

Relevant log output

AttributeError: 'NoneType' object has no attribute 'strip'

requirements.txt file

Where are you facing this problem?

Production Environment (explain below)

Function app name

No response

Additional Information

'os.getenv("erp_LANDING_STORE_CONNECTION_STRING").strip()' gives me the error "'NoneType' object has no attribute 'strip'".

This seems similar to some other reports here, but I am on python 3.11, not 3.13, on FlexConsumption: Runtime Stack Python - 3.11
Further, when I print all environment variables using 'logger.warning(f"Env vars: {dict(os.environ)}")' I see 87 environment variables, but not the "erp_LANDING_STORE_CONNECTION_STRING" variable for some reason.

What is even stranger is that sometimes it works, and then it stops working again when processing multiple messages. Maybe it has something to do with new instances not being set up completely during start and scale out:
ServiceBus message 1 - Succeeds
ServiceBus message 2 - Succeeds
ServiceBus message 3 - Succeeds
ServiceBus message 4 - Fails
...
ServiceBus message 33 - Fails

Sometimes a manual restart fixes the issue for a little bit.

[hallvictoria]

Hi @NoobsDeSroobs, thanks for reporting.

You mentioned that, when printing out all the environment variables, erp_LANDING_STORE_CONNECTION_STRING is not printed. How is this variable being set? Is it an app setting?

[NoobsDeSroobs]

@hallvictoria Hi again.

Sorry for the delayed response, but I spent most of yesterday trying to replicate the issue and I am starting to question my sanity as I have been unable to replicate the problem.

To answer your question and give more context, let me lay out the chronological events of the past few days.

We have had a linux function app with the serverless SKU for a while, working just fine and as intended.
We saw the need for some additional capabilities and decided to migrate over to the FlexConsumption SKU, and I made the requisite changes.
As before, the environment variable was set in the app settings, and the code and trigger bindings were unchanged. The only changes I made were to the terraform IaC.
When a full redeploy was made we found that the system failed with a confusing error, so we added more logs and eventually identified that one required environment variable, while present in the Azure portal GUI, was missing.
For several hours the problem was reproducable across all variations:

1. I tried python 3.10, 3.11, 3.12 and even 3.13. I am aware the documentation states there is no support for python 3.13 yet, but I also found some resources here on github saying you could get 3.13 to work.
2. I tried changing the permissions of the function app and gave it its own storage account and blob container with the fastest SSD option.
3. I tried deploying a second separate function app and saw the same issue.

I did originally deploy two Flex SKU Function apps to the same resource group, but then I ran into some issues and ended up separating them into two resource groups instead.
However, after all the testing above, and probably something else that I have forgotten, I gave up and went to bed after a quick deploy of our main branch to reset to a stable system.

The next day I redeployed the same flex consumption branch and restarted my testing. No issues.
I changed to 3.10, 3.11 and 3.12. No issues. I never managed to get 3.13 to work as the health check of the app and the bindings always failed, even though the code seemed to be updated.
I ran hundreds of concurrent heavy tasks through the function app, and no issues.
I artificially inflated some of the data payloads and nothing. New failures related to timeout in the service bus queue started popping up, but the function app was rock solid.

So either it was a temporary problem the day I did my original testing and made this bug report, or I have changed something through all my actions that fixed it.
Anyways, I am planning to deploy a parallel production environment using the Flex SKU and mirroring all traffic through it for a few days to verify that it does not happen again, and I will come back to you.
If you do not hear from me within a few days, then you can close this bug report.

[hallvictoria]

Thanks for your response, and I'm sorry to hear you've had so many issues with this migration. If the issue reoccurs and you're willing, you can also share the function app name, and we can take a closer look.

I am aware the documentation states there is no support for python 3.13 yet

To clarify on this comment, I'm assuming you mean that Python 3.13 is not GA yet. We do have support for Python 3.13, but it is currently in preview.

I'll set the issue to auto-close in 7 days if there's no further activity, but please feel free to re-open if the issue occurs again.