Improve extension startup error discoverability/logging

[v-galatrash]

The generated code from this code generation template is reporting the exception in the error stream but not passing it to the application (in this case the Azure Function) error handler. This caused me to waste few days chasing an issue where my function's failed to startup in the cloud. I couldn't find the issue until I downloaded the source code to my local machine and referenced the code directly in my solution to be able to debug locally and find what caused the failures.

This must remove the try/catch to allow developers more flexibility and control over their code.

[jviau]

@v-galatrash we can evaluate this change, but it would be a breaking change not doable within a major version or some opt-in switch.

This failure would happen at startup time. When you say "application error handler", what exactly are you meaning? Not catching this exception would most likely crash the entire process.

[v-galatrash]

@jviau crashing application at startup with a log of the exception is better than sending the error to the error stream (where I couldn't find it in the app-insights which in the end caused the application to crash anyway. IMO, libraries must not hide exceptions and should propagate them to the callers.

[jviau]

@v-galatrash I think it will be more productive if we focus on the issue and not a proposed solution. There may be a lot of nuance and context not captured here as to why we catch this exception (and avoiding crashing the process).

The issue as I understand it, is that it is hard to identify failures during extension startup. Can you expand on not finding it in app insights? Was, app insights not configured? Where you able to see this error locally?

[v-galatrash]

@jviau I don't see this error locally as the function uses my local credentials when accessing the blob storage (and receiving blob triggers) which works normally. I face the error in the cloud where I've switched to using managed-identity access.

App-insights is configured properly and I see other traces and exception, but I don't see the details logged through error stream (inside the auto-generated code - ("Error calling Configure on {{typeName}} instance."+ex.ToString())). If there is a way to direct this to an ILogger instance, then it will appear in app-insights.

[jviau]

Ah noticed this writes to Console.Error directly. Okay, that is something we can definitely look into and action on: improving error logging here. We can also at the same time look into what the impact of no longer catching the exception would be (or making it configurable).

[v-galatrash]

Just to make my point clearer, when you catch the error and don't propagate it, my code assumes it succeeded and proceeds thinking the configuration went without errors which causes more errors to occur at a later stage where the configured data is used while it wasn't initialized.

Please let me know when this behavior is improved/changed or a change plan is set forward.

[jviau]

Next steps:

1. Investigate impact of throwing for extension startup failure.
   • Verify throwing will expose failure to the customer for a deployed application.
2. If impact is acceptable, evaluating if this change should be opt-in or opt-out (preferably via AppContext switch)
3. Evaluate if we should be emitting this error via an alternative path (such as an EventSource), either in addition to letting the exception bubble out or instead of throwing.
   • Also design how customers will listen to this alternative path

[v-galatrash]

@jviau just to give further insights, when I downloaded the source functions worker source code and linked to it directly. I was able to retrieve this error:

Error calling Configure on Microsoft.Azure.Functions.Worker.BlobStorageExtensionStartup instance.System.IO.FileNotFoundException:
  Could not load file or assembly 'Microsoft.Extensions.Azure, Version=1.7.4.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.
  The system cannot find the file specified.
File name: 'Microsoft.Extensions.Azure, Version=1.7.4.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'
   at Microsoft.Azure.Functions.Worker.FunctionsWorkerApplicationBuilderExtensions.ConfigureBlobStorageExtension(IFunctionsWorkerApplicationBuilder builder)
   at Microsoft.Azure.Functions.Worker.BlobStorageExtensionStartup.Configure(IFunctionsWorkerApplicationBuilder applicationBuilder) in C:\Code\ExternalRepos\azure-functions-dotnet-worker\extensions\Worker.Extensions.Storage.Blobs\src\BlobStorageExtensionStartup.cs:line 21
   at AkamaiLogParser.WorkerExtensionStartupCodeExecutor.Configure(IFunctionsWorkerApplicationBuilder applicationBuilder) in C:\Code\aka.ms\Services\API\src\AkamaiLogParser\obj\Debug\net8.0\Microsoft.Azure.Functions.Worker.Sdk.Generators\Microsoft.Azure.Functions.Worker.Sdk.Generators.ExtensionStartupRunnerGenerator\WorkerExtensionStartupCodeExecutor.g.cs:line 22

I added a reference for the missing DLL Microsoft.Extensions.Azure, in my project, and it started working locally, but when deployed to Azure, it is still not initializing the connection string / service URI.