Steps:

1. run tests via debug
2. have a breakpoint on the test which it hits
3. using the debugging control bar, click restart 3 times (each time the run again gets stopped at the set breakpoint)
4. 🐛 on the 3rd time restarting the test, the test will no longer hit the break point, or finish and if you look at the test explorer the UI will still spin

Details on debugging this issue:

I have narrowed down the issue with the fs path check and it is related to the creation of the reader stream but only on mac (fifo related). I tried on windows, and cannot get the bug to occur but both @anthonykim1 and I get it on mac. I narrowed it down to the line const reader = fs.createReadStream(pipeName, { encoding: 'utf-8' }); by running a test. I put the following code before and after the line, and after the line it stalls while before it succeeds:

        for (let i = 0; i < 15; i = i + 1) { 
            const z = await Promise.race([
                fs.pathExists(
                    '/Users/eleanorboyd/vscode-python/src/client/testing/testController/pytest/pytestExecutionAdapter.ts',
                ),
                new Promise((_, reject) => setTimeout(() => reject(new Error('Timeout')), 5000)),
            ]);
            console.log(`META z ith time:`, i, z);
        }

I did this 20+ times in different spots and the before and after this single line and it holds. So it looks like the creation of the reader creates a file lock - or at least causes it to mess up after multiple times. I attempted: changing the reader and writer to only allow for 64 bits of info transferred, only impact is making it stall sooner. I also moved the code which it kept breaking on before the creation of the reader which caused that code to no longer fail, but more code (I assume just more file access since there are so many places that might happen) fail after the reader is created.