Host IDs

Overview

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.

Host ID Collisions

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:

1. Point your app at a different storage account.
2. 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.
3. Provide an explicit Host ID for your app(s) so they don't conflict anymore (see below).
4. 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.

Host ID Override

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. More documentation here on this.

When providing an explicit Host ID, you may see a warning "Host id explicitly set in configuration. This is not a recommended configuration and may lead to unexpected behavior." logged. This warning is logged because using an explicit ID isn't common and can lead to issues if done incorrectly. The main issue this could cause happens if you're sharing the storage account between different Function Apps using the same Host ID (including local development scenarios). The host ID is used as a scoping property that uniquely identifies an application (in things like distributed locks, storage operations, application insights logs, etc.). If those applications share those resources, you may run into issues where they'll be doing things like competing for locks across deployments/local. You can safely ignore this error if you're aware of these considerations.