CrescendoNativeErrorQueue and -ErrorAction Stop

[MTI-gh]

Summary of the new feature / enhancement

I updated a module to use v1.1 and handle errors using Pop-CrescendoNativeError -EmitAsError.
The command-line tool quser.exe sends two error messages when a remote machine cannot be reached so this puts two messages in the __CrescendoNativeErrorQueue.

When using the -ErrorAction Stop parameter on the function it will trigger on the first error as expected. However the second message is still in the ErrorQueue. The next time the command is run, it will spit out that remaining error message even if the command is succesful.

I've tried to illustrate the behaviour in the screenshots.

Proposed technical implementation details (optional)

It's open for discussion on whether this is an issue that needs to be solved or if the onus is on us to make changes according to our needs for the module.
Right now, to solve the problem I tweaked the function Pop-CrescendoNativeError to group multiple messages into 1 and write the errormessage only when the CrescendoNativeErrorQueue is empty.

[theJasonHelmick]

Hi @MTI-gh -- This is by design -- you need to set your output handler to streaming mode to handle the errors one at a time. Here is an example of streaming:

           "OutputHandlers": [
                {
                    "Handler": "$input|ConvertFrom-CSV",
                    "StreamOutput": true,
                    "ParameterSetName": "Default"
                }
            ]

Let me ask @JamesWTruher if he has thoughts as well.

[JamesWTruher]

@MTI-gh
This also may be associated with PSNativeCommandUseErrorActionPreference (could you let me know what that value is for you) - this will sometimes result in 2 error records being posted (this is done in the engine, where crescendo is out of the picture), which may be causing this behavior. I think for the purposes of crescendo, this variable should probably be set to false which means you'll only get 1 error record for each emission of the native app.

I've been thinking that this should be set to false by the proxy. If you set it to false and run again, does that problem go away?

[DennisL68]

           "OutputHandlers": [
                {
                    "Handler": "$input|ConvertFrom-CSV",
                    "StreamOutput": true,
                    "ParameterSetName": "Default"
                }
            ]

quser doesn't support CSV-output.

[theJasonHelmick]

thank you @DennisL68 for the information! Its been a long time since I have used quser -- and if it doesn't;t support structured output (css, json, etc) then you will need to create a custom outputted -- here is an article where Sean explains the process: https://devblogs.microsoft.com/powershell-community/converting-string-output-to-objects/

[DennisL68]

Yes, I know (and I already have a working parser for quser.exe) :)

My point was only, that your proposed answer to handle the output of quser.exe, was to set the output mode to "StreamOutput".
But I assume that is only a feature that works with the built-in structured data handler?

How do we go about to handle this issue as described by @MTI-gh when actually wanting to use quser.exe?

Would a new feature of pre-parsing be a solution in this case?
I.e. I provide the function to parse the output and then use an option to "pipe it back" as json or csv to the Crescendo output handler?

[theJasonHelmick]

@MTI-gh -- We are aware of two issue, one being $PSNativeCommandUseErrorActionPreference, which when true, will cause two errors to occur for any single native error. The other is the queue of errors (__CrescendoNativeErrorQueue) was global in the module, which means once the proxy execution is complete, the queue was not emptied and those errors would remain. We are planning on addressing both of these. Thank you for the issue

[MTI-gh]

Sorry for the late reply, life's been busy.

@JamesWTruher I did try with $PSNativeCommandErrorActionPreference set to $false but it had the same result. I had to enable this feature with Enable-ExperimentalFeature so I don't think it was playing the issue back when I did the testing in March. When set to $true it did produce an additional error message Program ended with non-zero exit code: 1

@theJasonHelmick, @DennisL68 Thanks for the follow-ups!

[JamesWTruher]

commit f2a1208 explicitly sets PSNativeCommandErrorActionPreference (which should solve some of the issue). I also changed the architecture to make the error queue local to the cmdlet rather than being global to the module. That should take care of the -Stop issue because every instance of the cmdlet should have the queue as a local variable.

[theJasonHelmick]

Thank you! Fixed/closed - in release: https://www.powershellgallery.com/packages/Microsoft.PowerShell.Crescendo/1.1.0-RC1