Add explanatory comments

Author: Anthony Staples

src/RequestProcessor.cs

@@ -19,6 +19,7 @@
 namespace Microsoft.Azure.Functions.PowerShellWorker
 {
     using Microsoft.Azure.Functions.PowerShellWorker.WorkerIndexing;
+    using Microsoft.PowerShell;
     using System.Diagnostics;
     using System.Text.Json;
     using LogLevel = Microsoft.Azure.WebJobs.Script.Grpc.Messages.RpcLog.Types.Level;
@@ -124,6 +125,10 @@ internal StreamingMessage ProcessWorkerInitRequest(StreamingMessage request)
                 RemoteSessionNamedPipeServer.CreateCustomNamedPipeServer(pipeName);
             }
 
+            // Previously, this half of the dependency management would happen just prior to the dependency download in the 
+            // first function load request. Now that we have the FunctionAppDirectory in the WorkerInitRequest, 
+            // we can do the setup of these variables in the function load request. We need these variables initialized 
+            // for the FunctionMetadataRequest, should it be sent. 
             try
             {
                 var rpcLogger = new RpcLogger(_msgStream);
@@ -136,8 +141,8 @@ internal StreamingMessage ProcessWorkerInitRequest(StreamingMessage request)
                 rpcLogger.Log(isUserOnlyLog: false, LogLevel.Trace, string.Format(PowerShellWorkerStrings.FirstFunctionLoadCompleted, stopwatch.ElapsedMilliseconds));
             }
             catch (Exception e)
-            {
-                // Failure that happens during this step is terminating and we will need to return a failure response to
+            {                
+                // This is a terminating failure: we will need to return a failure response to
                 // all subsequent 'FunctionLoadRequest'. Cache the exception so we can reuse it in future calls.
                 _initTerminatingError = e;
 
@@ -231,7 +236,7 @@ internal StreamingMessage ProcessFunctionLoadRequest(StreamingMessage request)
                 }
                 catch (Exception e)
                 {
-                    // Failure that happens during this step is terminating and we will need to return a failure response to
+                    // This is a terminating failure: we will need to return a failure response to
                     // all subsequent 'FunctionLoadRequest'. Cache the exception so we can reuse it in future calls.
                     _initTerminatingError = e;
 
@@ -366,7 +371,6 @@ internal StreamingMessage ProcessInvocationCancelRequest(StreamingMessage reques
 
         private StreamingMessage ProcessFunctionMetadataRequest(StreamingMessage request)
         {
-            // WorkerStatusResponse type says that it is not used but this will create an empty one anyway to return to the host
             StreamingMessage response = NewStreamingMessageTemplate(
                 request.RequestId,
                 StreamingMessage.ContentOneofCase.FunctionMetadataResponse,

src/WorkerIndexing/WorkerIndexingHelper.cs

@@ -19,23 +19,44 @@ internal static IEnumerable<RpcFunctionMetadata> IndexFunctions(string baseDir)
         {
             List<RpcFunctionMetadata> indexedFunctions = new List<RpcFunctionMetadata>();
 
+            // This is not the correct way to deal with getting a runspace for the cmdlet. 
+
+            // Firstly, creating a runspace is expensive. If we are going to generate a runspace, it should be done on 
+            // the function load request so that it can be created while the host is processing. 
+
+            // Secondly, this assumes that the AzureFunctions.PowerShell.SDK module is present on the machine/VM's 
+            // PSModulePath. On an Azure instance, it will not be. What we need to do here is move the call 
+            // to SetupAppRootPathAndModulePath in RequestProcessor to the init request, and then use the 
+            // _firstPwshInstance to invoke the Get-FunctionsMetadata command. The only issue with this is that
+            // SetupAppRootPathAndModulePath needs the initial function init request in order to know if managed
+            // dependencies are enabled in this function app.
+
+            // Proposed solutions: 
+            // 1. Pass ManagedDependencyEnabled flag in the worker init request
+            // 2. Change the flow, so that _firstPwshInstance is initialized in worker init with the PSModulePath 
+            //    assuming that managed dependencies are enabled, and then revert the PSModulePath in the first function
+            //    init request should the managed dependencies not be enabled. 
+            // 3. Continue using a new runspace for invoking Get-FunctionsMetadata, but initialize it in worker init and
+            //    point the PsModulePath to the module path bundled with the worker. 
+
+
             InitialSessionState initial = InitialSessionState.CreateDefault();
             Runspace runspace = RunspaceFactory.CreateRunspace(initial);
             runspace.Open();
-            System.Management.Automation.PowerShell ps = System.Management.Automation.PowerShell.Create();
-            ps.Runspace = runspace;
+            System.Management.Automation.PowerShell _powershell = System.Management.Automation.PowerShell.Create();
+            _powershell.Runspace = runspace;
 
-            ps.AddCommand(GetFunctionsMetadataCmdletName).AddArgument(baseDir);
+            _powershell.AddCommand(GetFunctionsMetadataCmdletName).AddArgument(baseDir);
             string outputString = string.Empty;
-            foreach (PSObject rawMetadata in ps.Invoke())
+            foreach (PSObject rawMetadata in _powershell.Invoke())
             {
                 if (outputString != string.Empty)
                 {
                     throw new Exception(PowerShellWorkerStrings.GetFunctionsMetadataMultipleResultsError);
                 }
                 outputString = rawMetadata.ToString();
             }
-            ps.Commands.Clear();
+            _powershell.Commands.Clear();
 
             List<FunctionInformation> functionInformations = JsonConvert.DeserializeObject<List<FunctionInformation>>(outputString);