ttrider / powershellasync Goto Github PK

Thank you for this great little library. It seems to work well apart from the fact that any exceptions that my cmdlets throw simply disappear. I propose that the behavior should be as close as possible to exceptions in synchronous cmdlets, i.e. exceptions should stop the pipeline and get printed out on the console.

Exceptions thrown in async code get wrapped in an AggregateException which is not very useful when printed on the console. Ideally, your library would unwrap these before rethrowing them, at least for the common case when there's only one inner exception.

Please. Thanks.

If I do this:

 var path = await ServiceLocator.Current.UpdateService.StartUpgradeAsync();
 ShouldContinue("my message.", "Exit this Powershell instance?");

The deadlock happens here:

However, if I do this:

 var path = await ServiceLocator.Current.UpdateService.StartUpgradeAsync();
 await Task.Run(() => ShouldContinue("my message.", "Exit this Powershell instance?"));

That Wait doesn't block, but instead the task gets pulled off the queue and invoked via the below as expected.

I think there's probably something that could be done to how methods like ShouldContinue are wrapped by PowerShellAsync to fix this:

For now, I'm moving forward by just wrapping CmdLet calls like ShouldContinue and WriteProgress which appear to not be correctlyl wrapped by PowerShellAsync with Task.Run calls. I don't grok this stuff well enough yet to propose a specific fix. I suspect it's very similar/related to #2.

See also: PowerShell/PowerShell#7690

Or, get me access so I can do it.

Thanks!

I ran into exceptions thrown by System.Management.Automation methods when trying to invoke script snippets from within the ProcessRecordAsync override of an AsyncCmdlet. More specifically, the exception originated from the System.Management.Automation.ScriptBlock.GetContextFromTLS() method. LocalPipeline.GetExecutionContextFromTLS() would always return null for some reason.

After some investigation, I realized that that, earlier in my Cmdlet's control flow, an async call was made whose continuation did not marshall back to the initial thread (appropriately called "Pipeline Execution Thread"), which led to the "CommandInvokedFromWrongThread" error.

The AsyncCmdlet logic should ensure that the tasks awaited from within the various 'async' method overload it exposes are marshalled back to that main thread specifically to avoid running into those issues.