-
Notifications
You must be signed in to change notification settings - Fork 87
Known issues with runspaces
Some built-in types have additional ScriptProperty objects added by PowerShell. A good example is the [guid] type which has a Guid ScriptProperty of {$this.ToString()}. Normally you could define a function parameter in the param() block like:
$MyParameter = [guid]::NewGuid().Guid,
However under heavy concurrent load it appears that there is a very small delay to initialising ScriptProperty methods such as this, which will result in random BeginInvoke errors in PoshRSJob.
Excellent workarounds are to directly access the underlying object property rather than going through a ScriptProperty (i.e. using .ToString()).
$MyParameter = [guid]::NewGuid().ToString()
You could also defer that initialisation until your begin {} block. This is only a problem in the parameter definition for functions and never anywhere else.
Exception calling "EndInvoke" with "1" argument(s): "You cannot call a method on a null-valued expression."
If you see this error message, check your code for a Write-Output, Write-Host, Write-Error, which are being passed a $null argument.
For example:
$something = $null # Unexpectedly
Write-Output $something
While this has no effect outside of PoshRSJob, under heavy concurrent load runspaces will occasionally fail with an error when this occurs. The reason for that is unknown. A fuller exception context is provided below:
ErrorRecord : Exception calling "EndInvoke" with "1" argument(s): "You cannot call a method on a null-valued expression."
WasThrownFromThrowStatement : False
Message : Exception calling "EndInvoke" with "1" argument(s): "You cannot call a method on a null-valued expression."
Data : {}
InnerException : System.Management.Automation.CmdletInvocationException: You cannot call a method on a null-valued expression. --->
System.Management.Automation.RuntimeException: You cannot call a method on a null-valued expression.
at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
at System.Management.Automation.PSScriptCmdlet.DoProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
--- End of inner exception stack trace ---
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
at CallSite.Target(Closure , CallSite , Object , Object )
TargetSite : Void ConvertToMethodInvocationException(System.Exception, System.Type, System.String, Int32, System.Reflection.MemberInfo)
StackTrace : at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at lambda_method(Closure , Object[] , StrongBox`1[] , InterpretedFrame )
HelpLink :
Source : System.Management.Automation
HResult : -2146233087
Functions which have SupportsShouldProcess will work as normal however the What If: output which would normally be output to screen by $PSCmdlet.ShouldProcess() outputs nothing in an RSJob. This is because it's not written to a normal stream and is instead handled in a special way by PowerShell with no known way to interact with it.
As a workaround you could use your own function that outputs to normal streams, or, potentially force override $PSCmdlet.ShouldProcess with your own wrapper ScriptMethod (though this would be cumbersome).