Reliability: detect readiness

[fsackur]

Summary of the new feature / enhancement

As a user, I want async code to run reliably without an arbitrary delay.

This is a design problem that comes from the hacks used to achieve functionality. The bug report is #1 .

To work around this, we have a delay in the async runner before starting user code. The 500ms default is fine on my machine, but not enough on slow build servers.

In code, we use reflection to inject the global session scope (which includes the function table) and the argument completer dictionaries into the async runspace. These structures are normally created by internal code that does other things, so we side step some engine mechanics. This invalidates some invariants about code that should be completed in the runspace initialisation before control is handed to user code.

The powershell repo is a lot of code. The stack trace in the debugger is always long and difficult to navigate. It is challenging to identify root causes - I suspect there's more than one way this breaks.

One thing that can be read from stack traces is that PSReadLine is usually in the Powershell stack trace (as seen with Get-PSCallStack) when the error is collection modified; enumeration may not continue. If we can figure out what mechanism loads PSReadLine, we could tackle that part of the problem.

There doesn't seem to be a hook for "runspace actually ready", and if there was, we'd likely have invalidated it. There is room for more experimentation with the OnIdle event.

The most easily-reproduced bug is when commands, e.g. from Microsoft.PowerShell.Utility, are not found.

Proposed technical implementation details (optional)

No response

[fsackur]

PSReadLine as of 2.3.6 sets a private field _delayedOneTimeInitCompleted. When that is true, we can be sure that PSReadLine is fully loaded.

[fsackur]

I think there may be a simpler way.

Assumption: when the prompt is rendered for the first time, everything is fully initialised (for our purposes).

Idea: set a breakpoint on the prompt script with an action attached. The action removes the breakpoint, so it's a one-shot action. The action triggers the async runner to start.

    $PSBP = Set-PSBreakpoint -Command prompt -Action {
        Import-ProfileAsync $AsyncProfile -Verbose @splat
        $PSBP | Remove-PSBreakpoint
    }

[fsackur]

Boo. Tried the breakpoint idea; still got the "stack empty" error.

[fsackur]

Set-PSReadLineOption has AddToHistoryHandler and CommandValidationHandler params, which take callbacks. Need to look at whether a breakpoint on those handlers can be hit when we want.