Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Reproducing the issue is not extremely easy, so before we invest a lot of time into standing up a git repository with reproducible artifacts, we wanted to get the issue out there and simply explain with screenshots. It is a non-functional issue that we believe was introduced by design changes made to the way stdout is processed in the latest 7.4 runtime, but we cannot be certain.

Essentially, the high-level reproduction of the issue is done by doing the following:

1. Create a node app
2. Install node-pty
3. Install express with a basic route to render a simple HTML page
4. Install xtermjs
5. Upon loading of web page, open a websocket
6. In websocket connect handler, fork pwsh process with node-pty
7. Setup stdin/stdout handlers to sync the websocket and pwsh process
8. Configure the front-end xtermjs terminal to bind to the websocket

At this point you have a fully working pwsh terminal in the front-end. We understand the above is very hand-wavy and the setup for this is not entirely trivial.

9. Paste in some text, such as "abcdefghijklmnop" to the terminal

Observe substantial difference in total round trips of websocket performing various control character seqeunces. (See attached screenshots for example of differences performing the copy/paste from step 8)

In a low latency environment, this appears to be a non-issue (e.g. when the process is hosted on the same machine as the client), but in a production environment where the client connects to a transient process hosted on a unix container running nodejs in an Azure Datacenter, the latency between stdin/stdout becomes substantial.

We want to at least get some eyes on this as it is a bit of complicated issue and there are some non-PowerShell components at play in the reproduction of the issue (the fact that the issue is really only noticed in a high-latency env where the client shell and process are hosted seperately)

Patrick Meinecke (@SeeminglyScience), tagging you as you appear to be highly knowlegeable of the changes introduced around native command byte stream processing to stdout and the experimental features that have gone into stable release of 7.4. We have no proof that this is related to these changes, but the nature of their domain make us think it is a possibility. Curious if anything here seems familiar or could be suspect for investigation. Thanks!

Expected behavior

I am not sure we can consider this a bug and therefore can expect the behavior to be as it was before. Assuming this new behavior related to the control sequences observed in stdout is by-design, it would likely require a re-design of these efforts to minimize the behavior.

Actual behavior

Control seqeunce goes back to simplified version or at least has a way to "opt-in" to old behavior if possible.

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.6
PSEdition                      Core
GitCommitId                    7.4.6
OS                             Ubuntu 22.04.5 LTS
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

Before (7.2)

Observe the total round trip between client and server requires only 4 total messages being sent.

Unlikely the below example, the host process doesn't send each individual byte that was pasted in one at a time back to the client, instead it processes all bytes at once and returns the entire, aggregated stdout as one single buffer making it much more performant.

After (7.4)

Observe that now, every individual character that was pasted into the terminal requires an entire round-trip to the server process where the entire shell buffer of all bytes on the screen are returned, then some kind of "control" byte is sent back to the host process and then the next set of the entire shell buffer is sent again, this time with 1 more character. You can see the "Length" of the message grows by 1 byte each time indicating that the bytes being pasted are being sent back individually. So if you were to paste simply "abc" into the terminal, the host process would send back something like this:

1. myshellprompt>a sent to client (with ansi-color bytes too)
2. Control character sent to server
3. myshellprompt>ab snet to client
4. Control character sent to server
5. myshellprompt>abc sent to client
6. Control character sent to server

The problem is exacerbated by pasting longer strings of text as the total buffer size increased and the message latency increases