Flood of 500 POST errors on WSL2

[boilednut]

Hello.

I'm running Jupyterlab on Ubuntu 18.04 running in WSL2. Most operations I attempt with the extension produce a flood of ServerApp 500 POST errors (like the screenshot below). Most, if not all, of the operations are nonfunctional -- typically producing an "Unable to get lock on the directory" error. Also, the operations take a surprisingly long time to fail/succeed (taking minutes as opposed to secs on the command-line); and, during the attempt, the git process uses an unexpectedly high amount of the CPU (25-50%).

JupyterLab v3.3.2 ... @jupyterlab/git v0.36.0 enabled OK (python, jupyterlab-git)

$ git --version git version 2.36.0

My remote repository is a another machine on my LAN; I use key-based SSH as the protocol

Thanks for any help you can provide.

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[fcollonval]

Hey @boilednut are you using another tool with git support on the same repository at the same time (like VS Code)?

[boilednut]

Hey. No, the only other utility being used in the git command itself. I also have JetBrains DataSpell installed on the Windows host machine (not in WSL); but, it's not being used. Thanks.

[fcollonval]

hmm... I can explain what is happening but I don't have an explanation why it is happening in your case (and therefore how to solve it).

The extension is checking that the repository is not locked before carrying out an action. This is done by looking for the .git/index.lock file within the repository. If it exists, it means a git action is in process. In that case (i.e. your case), we test every 0.1s for lock file existence. If it disappears, then the action is carried out. But if after 5s the lock file is still present, the action is aborted. That is what you are experiencing.

So the main thing I would look for in your case are:

• Does the lock file exists?
• Does it got suppress by time to time (indicating that some git actions are going on the repository)?
• What happen if you manually remove it (be sure to backup your repository before doing that)?

[Betristor]

I got this index file but not the index.lock file and I got three git processes in backend.

[boilednut]

Thanks. The lock file ('.git/index.lock') doesn't exist in my repository -- even during the period when errors are being generated. Also, command-line git operations work properly on the same repository during that same period.

[fcollonval]

I'm trying to get a work around for this - it looks that the lock in the code is preventing you to execute some tasks although git is not lock by itself. So this sounds like an hanging process or when that terminates in a way that it was not capture and therefore the lock was not released.

@boilednut your remote is access through SSH - how do you set the credentials? @Betristor does your remote needs credentials to be accessed? If yes, how do you set them up?

[boilednut]

I use key-based access to the remote. Thanks.

[gogakoreli]

Any updates on this? Also, I believe it shouldn't be 500 rather handled gracefully saying the proper error message?