azure-functions-host
azure-functions-host copied to clipboard
Azure
Maximum length of an environment variable
I'm using Azure Function App hosted on an S1 Linux plan and I've noticed that whenever I set (through Azure Portal configuration ui) environment variable which is longer than 53 characters then it's getting trimmed.
Example:
Environment variable name: Section1__Subsection1__Subsection1OfSection1__ConnectionString
Portal allows to set such environment variable and after saving it still displays full length of it. But when I go to Kudu and open an appsettings view I can see it's trimmed to Section1__Subsection1__Subsection1OfSection1__Connect.
Works fine when app is hosted on Windows plan.
Couldn't find it documented anywhere.
@fabiocav / @mhoeger , I am able to repro this scenario. Like explained, the Env variable shows around 50 characters while using Linux OS and more than 50 characters while using Windows OS in Kudu.
Is this something that could be corrected
We just hit this now, this is ridiculous... So glad this issue exists because it's just bitten us big time... 😖
@ahmelsayed - do you know why there's a max length on environment variables on Linux or would this be a question for Jenny's team?
I have opened an internal workitem to start enforcing this limit when an attempt is made to add such a long env. variable from Portal or other clients. This should prevent the key from getting clipped silently before being passed to the app and make the failures more obvious. We will also check if the allowed length should be longer than 64 characters as well.
For now are you able to work around this limitation by shortening the length?
@balag0 Yes, this limitation was easily worked around by just shortening the length :)
I just ran into this issue as well. Spent ages figuring out what the problem was. It would be good if this was somehow at least mentionned in the documentation
Or to increase the limitation in terms of length. Would love to know the reasoning behind it.
The docs should be updated soon. The limit has been set to 100 characters based on the telemetry. Adding an env. variable name with a length longer than that would fail right away instead of getting truncated at runtime (once the changes are deployed ETA to start : 2-3 weeks).
The docs should be updated soon. The limit has been set to 100 characters based on the telemetry. Adding an env. variable name with a length longer than that would fail right away instead of getting truncated at runtime (once the changes are deployed ETA to start : 2-3 weeks).
100 is still a small amount for those of us who use nested configs, especially as double underscore __ is the nested structure identifier which wastes two chars per level.
Here is an example of the limit of 100 being passed with a setting. This is I believe still the recommended way of overriding host.json settings:
AzureFunctionsJobHost__logging__applicationInsights__samplingSettings__samplingPercentageDecreaseTimeout
Longterm we need a different solution for configuring nested configs via app settings. But we can increase the limit to 150 short term to improve things a bit.
Hi @balag0 Has there been any updates on increasing the limit? Just hit the limit of 100 today while attempting to deploy AzureFunctionsJobHost__logging__logLevel__Microsoft__Azure__WebJobs__Extensions__Storage__Blobs__Listeners__BlobListener as an appsetting.
Thanks
This is a silly limit, not sure why it is actually an idea at all.. we've been using it to override AzureFunctionsJobHost__logging__applicationInsights__DependencyTrackingOptions__enableSqlCommandTextInstrumentation running on Windows for ages and now we're in the process of migrating our Azure Functions to run on Linux and hit this one.. just for giggles I took it out of the CICD pipeline deployment so I could at least have the deployment complete and then went and manually added this setting and the Function still runs without any issues so I don't see why to limit this at all if it is allowed from the AZ Portal and it still seems to work on Linux.
