-
Notifications
You must be signed in to change notification settings - Fork 441
Host IDs
The Functions Host uses a Host ID to uniquely identify a particular Function App. By default, the ID is auto-generated from the Function App name, by taking the first 32 characters. In advanced scenarios, the ID can also be specified manually via App Settings (see below). This ID is used by the platform to store per-app correlated control/tracking information in the storage account.
If you have multiple Function Apps sharing a single storage account and they're each using the same Host ID (generated or explicit), that can result in a Host ID collision. For example, if you have multiple apps with names longer than 32 characters their computed IDs may be the same. Consider two Function Apps with names myfunctionappwithareallylongname-eastus-production and myfunctionappwithareallylongname-westus-production that are sharing the same storage account. The first 32 characters of these names are the same, resulting in the same Host ID myfunctionappwithareallylongname being generated for each.
When multiple apps are using the same Host ID (a collision), this can result incorrect behaviors. For example, some triggers like TimerTrigger/BlobTrigger store tracking info by Host ID and can behave incorrectly when multiple apps use the same ID.
In Functions v3 we added detection for this situation and a warning will be logged. In Functions v4 when this situation is detected an error will be logged, and the host will shut down (hard failure).
Options for addressing collisions:
- Point your app at a different storage account.
- Rename your app to something less than 32 characters in length. This will change the computed Host ID for the app and remove the collision.
- Provide an explicit Host ID for your app(s) so they don't conflict anymore (see below).
- In the case of v4 hard failure, you can disable this error via the
FUNCTIONS_HOSTID_CHECK_LEVEL
app setting. Only do this if none of the options above are possible for you. Possible values for this setting are "Warning" and "Error".
Note: Pointing an existing Function App to a new storage account or changing its Host ID can impact function processing. For example, BlobTrigger tracks whether it's processed individual blobs by writing "receipts" under a Host ID path in storage. If the Host ID changes or you point to a new storage account, that can lead to blobs being reprocessed. For a new app that hasn't processed work yet, this won't be a problem.
More details on this general issue can be found here.
You can specify an explicit Host ID for your app via app settings:
-
AzureFunctionsWebHost__hostId
(Windows and Linux) -
AzureFunctionsWebHost:hostId
(Windows only)
The value for the ID must be are under 32 characters in length. Other restrictions the value must satisfy are here. An easy way to generate an ID would be to take a GUID, remove the dashes and make it lower case, e.g. 1835D7B5-5C98-4790-815D-072CC94C6F71 => 1835d7b55c984790815d072cc94c6f71
- Configuration Settings
- function.json
- host.json
- host.json (v2)
- Http Functions
- Function Runtime Versioning
- Official Functions developers guide
- Host Health Monitor
- Managing Connections
- Renaming a Function
- Retrieving information about the currently running function
- Site Extension Resolution
- Linux Consumption Regions
- Using LinuxFxVersion for Linux Function apps
- Out-of-proc Cancellation Tokens
- Assembly Resolution in Azure Functions
- ILogger
- Precompiled functions
- Official Functions C# developer reference
- Contributor Onboarding
- Development Process
- Deploying the Functions runtime as a private site extension
- Authoring & Testing Language Extensions
- Bindings in out-of-proc
- Language Extensibility
- Worker Capabilities
- Investigating and reporting issues with timer triggered functions not firing
- Sharing Your Function App name privately
- Azure Functions CLI release notes [moved here]
- Function App Zipped Deployment [deprecated]