Background
On Azure PaaS, it is well known that Application Initialization can assist in “warming up” your Sitecore application when scaling up or swapping slots, so that your App Services instances aren't thrown into rotation to receive traffic when they aren't ready.
Unfortunately, since Sitecore 9.1, there is a nasty Owin error that prevents this from working correctly and this in turn impacts the healthy signaling of your App Services.
Strangely, the error would disappear after about 2 minutes.
Sitecore Support Response
After talking with Sitecore Support engineers, they ended up telling us that using <applicationInitialization> had not been tested for Sitecore, and that they don't have any official guidelines on configuring Azure App Initialization.
Finally, they said that they were not able to provide us with any assistance.
Cause
I started deciphering the problem on my own.
Looking at this error, the key to understand its root was on line 6: the BeginDiagnostics processor.
1: [InvalidOperationException: No owin.Environment item was found in the context.]
2: System.Web.HttpContextExtensions.GetOwinContext(HttpContext context) +100
3: Sitecore.Owin.Authentication.Publishing.PreviewManager.get_User() +15
4: Sitecore.Owin.Authentication.Publishing.PreviewManager.GetShellUser() +23
5: Sitecore.Pipelines.HttpRequest.BeginDiagnostics.ResolveUser() +41
6: Sitecore.Pipelines.HttpRequest.BeginDiagnostics.Process(HttpRequestArgs args) +43
7: (Object , Object ) +15 The BeginDiagnostics processor in the httpRequestBegin pipeline is used for Sitecore's diagnostic tools. This determines what happens if you try to run in Debug Mode in the page editor.
In this case, the PreviewManager User property was trying to return the HttpContext.Current.User which was not available yet, and was returning null and the error “No owin. Environment item was found in the context.” was thrown.
The Fix
After determining what was causing this error, the fix was simple. The processor isn't needed on Content Delivery instances as Debug Mode is only used on the Content Management instances.
Removing the processor via a simple patch fixed the error: