Gitpod: Workspace goes offline and unresponsive when pushing to github

[codemzy]

Describe the bug
Recently, my workspace tends to go offline and become unresponsive when I am pushing to github, or committing to git. It's only a temporary thing, the offline banner flashes at the bottom, then it will go away, but the workspace is unresponsive and I can't click anything in the workspace. It comes back usually within 30 seconds, and anything I have clicked while it was unresponsive pops up.

Plus, if I check the repo on github during the time it's unresponsive, it has been updated with the commits (like it will say... 'updated 1 minute ago' but the workspace will still be unresponsive, and then shortly after it will be responsive again.

To Reproduce
Push commits to github? It doesn't seem to happen all the time, but has started happening very frequently this week.

Expected behavior
It used to just push to github, display a little rotating symbol, and and then be done.

Hope that all makes sense!!

[jankeromnes]

Hi @codemzy, thank you for this bug report! And we’re sorry that this is happening to you.

In general, a yellow bottom bar means that Gitpod’s WebSocket connection is being unresponsive. This can be caused by several things:

1. the network is slow/unreliable
2. the front-end’s event loop is blocked by a long-running script
3. the backend container is slow to respond

Given that this only happens when you push to GitHub, and that the entire UI freezes up, we believe 2. is most likely the culprit, i.e. some script is briefly using up all the available performance in your browser tab process every time you commit or push.

• Does this happen with every repository, or just one in particular?
  
  
  
  • If it’s the latter, are you able to share its URL, so that we may try reproducing the bug?
  
  
• Do you have any VS Code extensions installed in the affected repository?
• Any browser extensions that could somehow interfere with Gitpod’s front-end code?

Also, if we consider possibility 3. (slow backend container), do you have any pre-commit-hook or push-hook enabled in your project? E.g. maybe some sort of linting or checking process that could accidentally slow down / make the backend container unresponsive.

[codemzy]

Thanks for looking into this for me...

I've done a little more digging, and it does seem to be an issue with just one repo (a private repo). In fact, not even the whole repo, just the dev branch I am working on. Weird.

I tried creating a new gitpod workspace for that branch, and the same issue occurs. It's not actually when I am pushing to github, but just when it communicates with github in anyway. For example, when I first open the workspace, if I click that little refresh icon at the bottom, if I add a commit locally, and when I push to github.

So, I tried creating a new branch from that branch on github, and then creating a workspace of the new branch - called dev instead of app-dev but I get the same problem.

Finally, I tried a different browser (firefox instead of chrome) - same problem. Instead of the "this page is unresponsive" error from chrome, firefox says "a webpage is slowing down your browser" and I click wait, but with firefox it seems to take longer to come back responsive and keeps showing that error.

So, just some further info for you, but in answer to your questions

• Just one branch of one repo
• No VS code extensions
• No browser extensions causing it as doesn't happen with other workspaces (and happens on firefox also which I have no extensions on)

I'm a bit stuck!!

It's a private repo - so I can't really share the URL. But its in my workspaces (app-dev branch) if you are able to take a look that way?

Let me know if you need anymore info and thanks for your help.

[codemzy]

Ok, I think I have found the problem, after creating another branch and applying my changes one by one. It seems that, as I am using tailwindcss during dev mode (because I don't minify or purge the css I am not using during dev mode), it results in quite a big (54427 lines (41133 sloc) 857 KB) .css file being created on my build - which was basically causing the issue for whatever reason (probably because it's such a big css file).

Anyway, I've added it to .gitignore (since it's a build file that didn't need to be on git) and now I do still get a flash of the 'offline' banner and the unresponsive behaviour but it seems to come back responsive within 5 seconds which is much better.

[codemzy]

Just to update, I think this repo had a lot of bloat with history etc because images and dist files had been committed, and I don't think that was helping matters (I guess with gitpod reading from github). I have created a new repo and moved the code across and this has resolved the issue completely. I've gitignored the dist files so hopefully this won't happen again!

[jankeromnes]

Wow, thanks @codemzy for diving deep into this problem and figuring it out. 💯 Sorry that we couldn't help you more in that process, but I'm happy that you're no longer facing the long disconnects.

I still suspect that there is a performance bug in Gitpod's Git integration though. Even when some code files get very large, I believe that GitHub and git themselves should still be able to cope fairly well. For example, if in some situation, using our Git GUI makes the IDE unresponsive for a while, but doing the same operation using git in the Terminal works fine, then it would very likely mean that we have a perf bug.

If this problem comes back, please re-open this issue, and we'll figure out a way to further investigate this (e.g. by privately sharing a Snapshot of your private repo, or by capturing such a yellow-bar event in a browser devtools performance profile).

[kk86bioinfo]

It seems this issue happening again now with my workspace. Upon workplace is loaded, it attempts to sync github but it render the site unresponsive and prompting slow/halting javascript alert asking to stop or wait.

[kk86bioinfo]

It seems related to github branch that I created from gitpod. I have re-create a new master repo for that branch and now it seems fine. Most likely there is some part on github integration for branches is not stable.