Report startup failures in the app Log Stream

[liliankasem]

An example surfacing logs properly is this issue where the worker crashes and the host restarts, but this information is not logged to users as errors. The host process was not able to start the worker process and it logged the startup exception as information

Customer comment: "the startup failures are being reported to Insights (and not appearing at all in the Log Stream of the app). It should've been logged as an error
and it should also have appeared in the Log Stream."

// Scope: clusters/wawscus/databases/wawsprod
let st = datetime(2021-12-09T13:26:43.8280758) - 5m;
let et = datetime(2021-12-09T13:26:43.8280758Z) + 5m;
FunctionsLogs
// | where PreciseTimeStamp > ago(30d)
| where PreciseTimeStamp between (st..et)
| where AppName =~ "testesgerais-dev"
| project-reorder PreciseTimeStamp, Summary, FunctionName, Details, HostVersion

User story: Log startup failures in the app Log Stream 

[fabiocav]

Since this is in Application Insights today, we should ensure that:

• Initialization errors have the appropriate level in app insights
• We log to diagnostic events, so when that comes online, that information is available in the portal

Let's repro with an initialization erros (perhaps using the setup referenced by @liliankasem) and validate the above requirements.

[satvu]

I used this comment from the issue @liliankasem linked to try to repro a startup failure, and no initialization errors were surfaced on dotnet-isolated. You could try to execute a function (but it would fail).

I also used the same repro mentioned above with a faulty use of AddUserSecrets to test out an in-proc .NET 6 app, and the error was caught immediately and the host never started up successfully.

Also going to try to repro this startup failure mentioned in the same thread since two people ran into the same problem.

[liliankasem]

I used this comment from the issue @liliankasem linked to try to repro a startup failure, and no initialization errors were surfaced on dotnet-isolated. You could try to execute a function (but it would fail).

I also used the same repro mentioned above with a faulty use of AddUserSecrets to test out an in-proc .NET 6 app, and the error was caught immediately and the host never started up successfully.

Also going to try to repro this startup failure mentioned in the same thread since two people ran into the same problem.

Can you upload both repros to a public github repo?

[satvu]

Samples:

• Inproc App of AddUserSecrets error for comparison here
• Isolated App of AddUserSecrets error here
• Isolated App Linux Program.cs Error failure here

I think the simplest one to use for investigation is the last one in the list above (Linux isolated app) because it is the simplest repro with no extra dependencies. It's just an HttpTrigger app with a few extra lines in Program.cs.

I was unable to repro the exact failure on the isolated app today for AddUserSecrets, and I'm unclear on what changed locally since the last run yesterday (package update? There's quite a few involved in setting up that repro and the dependencies differ between inproc/isolated even if the faulty code in Startup.cs is the same). However, you can still see that inproc fails immediately on deployment but isolated does not. If I get the exact repro again, I'll update the app.

[fabiocav]

We need to continue investigation here.

@satvu has the repros, so our next step should be to identify if there's an issue with the host (meaning, the worker wrote the failure details to stdout/error, and the host did not appropriately log them), or if there's an issue with the worker implementation.

[fabiocav]

Investigation on this was completed and some work derived from the results. Once the associated PR is merged, we should be able to close this item.