FileNotFound exception when file exists in cache in Azure - PhysicalFileCacheFileSystem uses Environment.MachineName in cachefolder path which is not reliable in Azure Web Apps

[aldermore-andyburbidge]

PhysicalFileCacheFileSystem uses Environment.MachineName in cachefolder path which is not reliable in Azure Web Apps.

From https://docs.umbraco.com/umbraco-cms/fundamentals/setup/server-setup/azure-web-apps

"Web worker migrations

It's important to know that Azure Web Apps may move your website between their 'workers' at any given time. This is normally a transparent operation. In some cases you may be affected by it if any of your code or libraries use the following variables:

Environment.MachineName (or equivalent)

When your site is migrated to another worker, these variables will change. You cannot rely on these variables remaining static for the lifetime of your website."

However in PhysicalFileCacheFileSystem.cs the cacheFolder variable uses Environment.MachineName

I have encountered File Not Found exceptions in scaled Azure web apps, so I have had to switch to in memory cache. However, this has a memory overhead when the app scales for high load.

I do not know what alternative value could be used for the file based cache, but this issue needs documenting at least for those who may also encounter this issue.

[Shazwazza]

When a site is moved to another worker in Azure, the site will restart. The new cache folder will just be the name of the new machine, which in theory will be empty so the cache will be rebuilt on that machine.

I'm not sure about the statement

You cannot rely on these variables remaining static for the lifetime of your website

Since when a site is moved, it is restarted and Environment.MachineName will be static/immutable.

The main thing about azure web apps is that the storage is in a shared location so when your site is on worker "A" and then moved to worker "B", the same storage is used (so long as you are not doing zip deployment/readonly).

I'd be happy to help investigate or have a work around, but I'm not sure if this is definitely the root cause.