Error handling

[mato]

This may not be a bug, I'm not a Powershell expert, but I don't know where else to ask:

Is there a way to reliably ensure that I get a clear indication on the Ruby side, when the Powershell command invoked by execute() results in an error or exception?

Trivial example:

irb(main):031:0> pwsh.execute('errorerrorerror')
=> 
{:exitcode=>0,
 :errormessage=>nil,
 :stderr=>[],
 :stdout=>
  "errorerrorerror: The term 'errorerrorerror' is not recognized as a name of a cmdlet, function, script file, or executable program.\nCheck the spelling of the name, or if a path was included, verify that the path is correct and try again.\n",
 :native_stdout=>nil}

I'd expect to get at least an :exitcode of 1, or any of :errormessage, :stderr populated. Instead, I get nothing, and the error text just shows up in :stdout.

If type errorerrorerror into an interactive pwsh session on Linux, then the error message is in red, so I'm assuming that Powershell "knows" it's an error?

Context: I'm trying to automate a bunch of Exchange maintenance using the EXOv3 Powershell module, but driving "what needs to be done" from a Ruby script, which connects to a bunch of other systems. If I get my EXOv3 invocations wrong, I get no indication on the Ruby side that the command(s) failed.

[jordanbreen28]

hey @mato, we are going to add an action item to investigate this. Could you supply us with some reproduction steps to get us up and running quicker? Thanks.

[mato]

@jordanbreen28 So, I started writing a long response with examples, but then re-checked my assumptions and I think this might just be the Exchange Online Powershell module's fault and not that of ruby-pwsh. See below.

This is all with Ruby 3.1.2p20, PowerShell LTS 7.4.5 installed as a Debian package from Microsoft's site. YMMV.

You need to have access to an Exchange Online instance to reproduce this. Assuming you've successfully authenticated by calling the Connect-ExchangeOnline cmdlet in the relevant PS session beforehand, then one simple way to reproduce is:

irb(main):030:0> pwsh.execute('Connect-ExchangeOnline')
=> 
{:stdout=>
  "\n----------------------------------------------------------------------------------------\nThis V3 EXO PowerShell module contains new REST API backed Exchange Online cmdlets which doesn't require WinRM for Client-Server communication. You can now run these cmdlets after turning off WinRM Basic Auth in your client machine thus making it more secure. \n\nUnlike the EXO* prefixed cmdlets, the cmdlets in this module support full functional parity with the RPS (V1) cmdlets.\n\nV3 cmdlets in the downloaded module are resilient to transient failures, handling retries and throttling errors inherently. \n\nREST backed EOP and SCC cmdlets are also available in the V3 module. Similar to EXO, the cmdlets can be run without WinRM basic auth enabled. \n\nFor more information check https://aka.ms/exov3-module\n----------------------------------------------------------------------------------------\n\n",
 :exitcode=>0,
 :errormessage=>nil,
 :stderr=>[],
 :native_stdout=>nil}
irb(main):031:0> pwsh.execute('Add-DistributionGroupMember -Identity xyzzy')
=> 
{:stdout=>
  "Add-DistributionGroupMember: Ex6F9304|Microsoft.Exchange.Configuration.Tasks.ManagementObjectNotFoundException|The operation couldn't be performed because object 'xyzzy' couldn't be found on 'AM0PR10A08DC001.EURPR10A008.PROD.OUTLOOK.COM'.\n\n",
 :exitcode=>0,
 :errormessage=>nil,
 :stderr=>[],
 :native_stdout=>nil}
irb(main):032:0> 

Compare with the same in an interactive PowerShell session:

PS /home/mato/1sg/git/scripts/entra> Connect-ExchangeOnline        

----------------------------------------------------------------------------------------
This V3 EXO PowerShell module contains new REST API backed Exchange Online cmdlets which doesn't require WinRM for Client-Server communication. You can now run these cmdlets after turning off WinRM Basic Auth in your client machine thus making it more secure. 

Unlike the EXO* prefixed cmdlets, the cmdlets in this module support full functional parity with the RPS (V1) cmdlets.

V3 cmdlets in the downloaded module are resilient to transient failures, handling retries and throttling errors inherently. 

REST backed EOP and SCC cmdlets are also available in the V3 module. Similar to EXO, the cmdlets can be run without WinRM basic auth enabled. 

For more information check https://aka.ms/exov3-module
----------------------------------------------------------------------------------------

PS /home/mato/1sg/git/scripts/entra> Add-DistributionGroupMember -Identity xyzzy
Add-DistributionGroupMember: Ex6F9304|Microsoft.Exchange.Configuration.Tasks.ManagementObjectNotFoundException|The operation couldn't be
performed because object 'xyzzy' couldn't be found on 'VI1PR10A08DC003.EURPR10A008.PROD.OUTLOOK.COM'.
PS /home/mato/1sg/git/scripts/entra> Write-Host $? $lastExitCode                
True 0

What you can't see above is that in the interactive session case, the error message from Add-DistributionGroupMember is in red, so I originally assumed that means it goes to stderr, and was expecting to see it there in the ruby-pwsh case.

Now it seems that is not actually the case? Further checking both $? and $lastExitCode above suggests that the ExO module is incorrectly returning a successful exit code from the cmdlet in a failure case.

[aaronlippold]

Has anyone reached out to MS support to see if we can have this issue resolved at the source?