-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Host ID Collision Error #2049
Comments
In the upgrade docs here it says you should "Use a separate storage account for each function app" and then links to this GitHub Issue. But in the docs here it says, "It's possible for multiple function apps to share the same storage account without any issues". It does go on to say that "... this approach isn't always a good idea in a production environment", but it doesn't say not to do it. Can this be clarified in the docs? |
Its okay from the point of functionality as function apps will not step over each other if multiple apps sharing the same storage account in general (except for the issue mentioned above). |
We ran into problems with this, using Functions v4, dotnet-isolated; however, the only symptom was that the job host constantly restarted, there were no errors nor warnings logged anywhere (while the constant stop-start was logged properly) (this was true for multiple functions, separately). The workaround we used is a slot-level config override for Could you please check how is it possible that there were no errors logged at all? That's all the logs we see:
|
Our v3 Functions instances are configured to use unique I understand that this setup would be impossible when using separate storage accounts, correct? |
We are still facing the same challenge... Any ideas regarding my context? |
I do not fully understand why we are geting this error from all of a sudden. we have several functionapps which share one storage account and some of the functionapp names are longer than 32 characters. But it worked for several years. Furthermore I do not understand where to find and check the host ids. IN the storage account under there are several entries but only one contains the name of one of our functions apps. The others are like this: functionsv3x64placeholdertemplat etc. etc. So for me it looks like you do not use the functionapp name to generate a host id but some other strange and weird method which really could not work ? AND why is this suddenly changed? |
i opened a new bug as this one is ignored by microsoft see Azure/azure-functions-host#10650 |
Motivation
This change is meant to address longstanding issue Azure/azure-functions-host#2015. The underlying issue is caused by the following things being true:
If these are all true, then there is a collision and you can end up with unexpected outcomes as the two apps share state.
When this issue is detected for an app a log will be written. In v4 this will be an Error. In v3 this will be a Warning:
"A collision for Host ID '{hostid}' was detected in the configured storage account. For more information, see https://aka.ms/functions-hostid-collision."
Impact
At the point in time when this issue was create, about 28% of v3 apps have a name subject to truncation. Of those, only apps that are sharing storage accounts would be affected, which is likely a much lower percentage.
Compat-mode support
There will be an app setting FUNCTIONS_HOSTID_CHECK_LEVEL that supports values Warning/Error. In v3 the default will be Warning, and in v4 it will be Error. By default when this issue is detected in v4 it will be a hard failure. As an escape hatch this app setting can be used to change back to warning if needed.
Alternatives
Yes we discussed alternatives, but none of those were acceptable.
Detection
The v3 warning can be used to detect this.
Support
The error will have an aka.ms link with documentation on the issue and the recommended course of action for affected customers to take.
Documentation
Documentation impact
Components impacted
Functions Host
Performance
No.
The text was updated successfully, but these errors were encountered: