Error writing to history when broadcasting input to multiple terminals

[bgshacklett]

Environment data

PS version: 6.0.4
PSReadline version: 2.0.0-beta2
OS: Windows 10, Version 1703 (Build 15063.1209)

Steps to reproduce or exception report

1. Open multiple instances of PowerShell in a terminal emulator which supports split panes and broadcasts (e.g.: ConEmu)
2. Open three splits, resulting in four total open panes.
3. Turn on broadcasting (ctrl+shift+G for ConEmu)
4. Enter a command such as ls and press the Enter key.

Expected behavior

The command runs in all panes and no error is thrown

Actual behavior

The command runs in all panes, but errors will be thrown stating that the history file could not be written to because it is being used by another process

[bgshacklett]

It seems like the solution to this may fall outside of the scope of PSReadline, but I decided to open an issue here so that it's documented at the very least.

[lzybkr]

The error is reported at most a couple times per process, otherwise it gets really annoying.

I do think it's important to report though, e.g. if some process is holding an exclusive lock on the file, your history isn't getting saved and you'd want to know that.

[bgshacklett]

There's no question that it's important to mention. I keep wracking my brain about how the failure could be avoided. Perhaps some kind of buffering + retry logic would make sense? I would raise the question, of whether it makes sense to store, for example, four entries of that same command versus a single entry. Is the history intended to be a 100% literal representation of every instance of a command running or is it intended to be more to provide helpful hints the way Bash does (to my knowledge Bash is not anywhere near as careful with persistence of history)?

[lzybkr]

In theory, the retry logic is already implemented, see here.

Based on the error, it seems like something is holding on to the file handle outside the mutex - so either I'm missing a using statement, or there is a side effect accessing the file that missed.

[copdips]

Hello,

I've the same issue here with psreadline v2.0.0 with pwsh v6.1.0 inside conemu v180626 with split-terminal with keyboard broadcasting.

Idealy, it would be nice if we can silently ignore the error by a psreadline switch.

[copdips]

I just checked the source, is 100 ms too fast ?

[sleighsoft]

This also happens when you programmatically open two terminals at the same time. This can be done with the "Terminals Manager" extension of VSCode, for example. You just configure two or more terminals and "Run Terminals" It will then throw Error reading or writing history file 'C:\Users\...\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt': The process cannot access the file 'C:\Users\...\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt' because it is being used by another process.

[StevenBucher98]

I dont have a way to reproduce the exact scenario but I have tested on Windows Terminal preview that has broadcasting inputs and seems to work fine. If this is still an issue for you please open a new issue after testing on the latest version of PSReadLine. Thanks!

[corbob]

@StevenBucher98 This appears to be what I mentioned at PSHSummit Thursday. I've realized I'm not currently running the latest release, and also cannot currently reproduce it. I'll do some upgrading and testing and open a new issue if I can reproduce.

Here is the screenshot I took, the one getting the error is Windows PowerShell running PSReadLine 2.0.0. I was able to one time reproduce it on PowerShell 7.4.1 and PSReadLine 2.3.4.

[StevenBucher98]

Awesome thanks @corbob! if you run into the issue again definitely submit an issue and we can figure out how to fix it.