proxb / PoshRSJob

Provides an alternative to PSjobs with greater performance and less overhead to run commands in the background, freeing up the console and allowing throttling on the jobs.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Write-Stream throws lots of spurious errors on missing variables

codykonior opened this issue · comments

While running hundreds of jobs which return a mix of output, I've encountered issues when doing Receive-RSJob which look like this:

Write-Verbose : Cannot bind argument to parameter 'Message' because it is null.
At C:...\PoshRSJob\Private\WriteStream.ps1:17 char:107

  • ... Job | Select -ExpandProperty Verbose | ForEach { Write-Verbose $_ } }
  •                                                                ~~
    
    • CategoryInfo : InvalidData: (:) [Write-Verbose], ParameterBindingValidationException
    • FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.WriteVerboseCommand

Which in turn (appears to) trigger these:

WriteStream : Exception calling "EndInvoke" with "1" argument(s): "The property 'Arguments' cannot be found on this object. Verify that the property exists."
At C:...\PoshRSJob\Public\Receive-RSJob.ps1:102 char:18

  •         $_ | WriteStream
    
  •              ~~~~~~~~~~~
    
    • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,WriteStream

WriteStream : Exception calling "EndInvoke" with "1" argument(s): "The WriteObject and WriteError methods cannot be called from outside the overrides of the BeginProcessing, ProcessRecord, and EndProcessing methods, and
they can only be called from within the same thread. Validate that the cmdlet makes these calls correctly, or contact Microsoft Customer Support Services."
At C:...\PoshRSJob\Public\Receive-RSJob.ps1:102 char:18

  •         $_ | WriteStream
    
  •              ~~~~~~~~~~~
    
    • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,WriteStream

This is on PowerShell v5, PoshRSJob 1.7.2.7, with Set-StrictMode -Version Latest and $ErrorActionPreference = "Stop". I always do this to catch scripting errors.

I've modified the code to do this:

               "Verbose" { $IndividualJob | Select -ExpandProperty Verbose | Where { $_.Message } | ForEach { Write-Verbose $_ } }
              "Warning" { $IndividualJob | Select -ExpandProperty Warning | Where { $_.Message } | ForEach { Write-Warning $_ } }
              "Error"   { $IndividualJob | Select -ExpandProperty Error | ForEach { Write-Error $_ } }
               "Output"  { $IndividualJob | Select -ExpandProperty Output }

This avoids a lot of the errors. But it changes the semantics of Error because it discards a lot of info, and this still isn't working perfectly (I think).

Errors are a little fun in runspaces, especially when we are trying to capture them from a runspace. Do you happen to have some code to add to this that I use to duplicate the issue? It sounds like you have a partial solution that I can test with and possibly integrate into the module.

I believe that this should be fixed in v1.7.3.3

@codykonior Any chance that you might be able to revisit this and see if anything is better?

I'm just not sure why you are selecting out only some of the properties and then rewriting only some of the properties to the host.

Why not just return the full object? The outcome is the same except that the user can do what they like with the objects and all the other information they contain instead of, say, only seeing the message property.

Sorry, I'm drawing a blank on this. Can you point me to the file/line that you are seeing this on? It may better help to remember why I did it the way that I did...or make me realize that I should do it differently.

Edit: I see what you are saying now. Can't tell you why I rolled with that approach but it is something that I can update to pull the full object vs. just the message property.

I believe that I saw you fixed this (whole object vs. just Message property) in your latest PR. Are things looking better now?

I checked WriteStream and it's still your original version - I only expanded the existing names. I have been using a private version for the past year which does the full objects but I didn't merge it as I wanted to keep the PR just on fixes and cleanups.

Got it. For some reason I thought I saw otherwise, but going back I apparently wasn't paying attention. It's all good as I will work that into the next update.

No longer an issue as far as I know.