It turns out that force stopping pyright with Ctrl+C during the time a loading bar is visible on the screen (presumably npx running something), some crucial cleanup work is skipped, and a folder named .pyright-random_string stays present in the node modules directory (as an example of full path for my case: /home/itsdrike/.local/share/npm/_npx/77993788984d59ab/node_modules/.pyright-WRkpBM9m) when it should have gotten removed.

Because this folder didn't get deleted, running pyright the next time leads to problems from npx, detecting that the directory it wants to make is already there, and ending with 217 error code, which doesn't give the user any description on what happened (because of the --silent flag). This is the actual error output from npx when using it manually to see the messages it produces (without silent):

Full traceback of the keyboard interrupt error propagation which did lead to this folder not getting removed:

Traceback (most recent call last):
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/bin/pyright", line 8, in <module>
    sys.exit(entrypoint())
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/site-packages/pyright/cli.py", line 81, in entrypoint
    sys.exit(main(sys.argv[1:]))
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/site-packages/pyright/cli.py", line 21, in main
    return run(*args, **kwargs).returncode
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/site-packages/pyright/cli.py", line 57, in run
    return node.run('npx', *pre_args, f'pyright@{version}', *args, **kwargs)
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/site-packages/pyright/node.py", line 112, in run
    return subprocess.run(node_args, env=env, **kwargs)
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/subprocess.py", line 503, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/subprocess.py", line 1141, in communicate
    self.wait()
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/subprocess.py", line 1204, in wait
    return self._wait(timeout=timeout)
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/subprocess.py", line 1938, in _wait
    (pid, sts) = self._try_wait(0)
  File "/home/itsdrike/.local/share/pyenv/versions/3.10.3/lib/python3.10/subprocess.py", line 1896, in _try_wait
    (pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt

I actually already encountered this issue a good while ago, but I had no idea what was causing it and it ended up getting resolved by deleting the folder made by npx holding pyright. I mentioned this in #37, and since that, I did encounter the issue a few times again, but I blamed it on npx running poorly with Arch Linux, or something like that. However after a lot of debugging, I finally figured out why this was happening.

When running pyright with npx alone outside of using this library (running through python's subprocesses), npx is able to handle Ctrl+C occurring and gracefully exits after a while (taking it's time to remove this temporary folder, and perhaps do some other cleanup too). This can be seen from this error message:

However running pyright through the script this library provides only produces the python's traceback error, and leads to the main python process being stopped, which then most likely kills the npx subprocess forcefully, and prevents it's cleanup from running.

This should be handled by catching the KeyboardInterrupt while waiting on the npx process, and if it was catched, ending the process gracefully and waiting for it to close before actually exitting the python script (perhaps by re-raising the exception, or with a simple message and sys.exit call with non-zero code).

Since npx can take a while (few seconds) for it's cleanup to occur, and the script is running it with the --silent flag, it would probably be a good idea to also print out some message about this closing processes getting started immediately after the user pressed ctrl+c, to avoid them pressing it again, and causing another keyboard interrupt error during the graceful closing process, leading to this issue once again. Maybe even another handle which would that time indeed forcefully terminate the process, but also let the user know about this issue.