Change:
Potentially, upgrading to MongoDB 4 has broken the GitPod Development. I am looking into it, but here are the errors: Shortened Error (me trying to restart Mongodb, after an initial crash): <details<summarymongod --version</summary</details<details<summaryFull Error</summary</details<details<summaryPotentially relevant client error</summary</details
To the best of my knowledge no code changes were made to upgrade MongoDB on GitPod. The base image using MongoDB 4 needs to be looked at. In other words, the move to MongoDB 4.0.x (not same as 4.x) breaking GitPod is coincidental?
To be honest, I have no idea. The base image: Source: Docs: From what I can see, the docker hub provides no information about the image, but the GitHub repo suggests the image has not been updated in 4 months. To me, this suggests an issue definitely on our side.
That is pretty easy to confirm. On GitPod you should be able to checkout a commit (any commit) that was best known to working from a few days ago. A diff should bring you closer to the root cause, say for example a dependency update somewhere. But to prevent beating around the bush, I think we instead provide our own base image with requirements set in the local setup file. Let me know if you need help with this & thanks for looking into it.
Update: There is a high likelyhood I have been looking into the wrong section for where the problem is. Here is the original error which lead me to look into the database stuff: <details<summaryClient Error</summary</detailsSteps to reproduce: 1) Open any instance off fCC GitPod 2) Wait for client to finish developing 3) Open browser preview of app 4) See client crash with above error I tried killing the database, restarting it, and restarting the client, but the app crashes, everytime the browser tries to load.
I can't reproduce this, sorry! If I go to it just works. I know we've talked about this before, but do you have any special settings for GitPod besides Enable feature preview? Environment variables are the only thing I can see that might cause an issue.
Other than the Feature Preview, everything is bog-standard. I will try to disable FP.
Disabled Feature Preview Rebased fork against upstream <details<summaryNew Client Error (similar, but different)</summary</details
If you have a lot of work in progress branches, I would suggest pushing them up to your fork and starting with a clean workspace, then on you should delete everything that is old/stale. As a best-practice I would start with a new workspace (provided the work is saved elsewhere like pushing up to th remote fork) and getting rid of older workspaces.
Fork? That could be relevant. Could you drop the Gitpod link that you're using here.
I might be using the wrong word... all I meant is: Here is the link I sometimes use - depends on whether I am testing with changes or not:
All of my testing (outside of the open PR branch) has been with a new workspace. I regularly clean the workspaces. Positive this is not part of the issue on my end.
Quick question: Are you using the preview browser within the GitPod environment? What happens if you ignore the crash on the preview browser and just use the "open in a new tab" button: ! If you reload there, is it the same behavior?
I never use the preview browser - always the new tab view (full). Had not thought to try it there, but, if I am relegated to using the preview, I still would not use it...
Hmm, I was able to reproduce with a link from your fork in your previous comment. But the link from this main repo works A-OK. Is it the same case for you? Or is it broken no matter what you do? I know you rely on GitPod quite a bit, we are totally cool with you pushing branches directly up to the main repository as an exception considering the massive amounts of work you put into contributions. If there is anything we can do to unblock you we would be happy to assist. Sorry about not being able to troubleshoot. :(
I've one idea left to try, that's updating my own fork and seeing if I can repro. I'll have a go tomorrow.
This is the same for me. A workspace from appears to work as expected. So, it is just my fork (unless proved otherwise by Oliver)... I will report this to the GitPod GitHub. Thank you, both, for your time in this. If there is anything in particular I need to work on, then I will take you up on this. Thanks
Just to confirm: it seems like it's some weird problem with Shaun's fork. It's worth trying my fork , but I suspect it'll just work when you use my link.
Worst case you would need to delete and recreate your fork and PRs, which is going to be a pain.
Strangely, his fork doesn't work locally also.
After all of that, pointed out the issue - Gatsby had enrolled me into their super secret testing club, and the development server-side rendering broke the build. Is it worth it me opening a PR with the change to prevent this? Or, am I really just that lucky?
Well, congrats on being the secret list that you never subscribed to (I hope?)!! Please make a PR to make sure no else gets on the exclusive club list and is surprised. We wasted so much time for no reason. Lolz.
Sorry this has been breaking you. This error line: comes from This generally works as most people run from the root of their site so equals the root of their site. I'm not sure what your setup is but I'm guessing you're starting the dev server differently? This isn't what we normally do — we have a more robust way to get the public directory that's not being used here that I'll switch this too which should unstick you.
Hey Thanks for getting back to us. You are correct we do have a non-common setup. We essentially use in parallel mode for spinning our API and the client (Gatsby) apps. Even within the client, we need to do a pre-Gatsby develop step. We package a few things (with Webpack) to for one of our client-side runtimes before bringing up Gatsby to start the dev server the normal way. Anyways while we do not understand the internals of Gatsby for this particular feature yet owing to time (BTW, Gatsby 3.x is fast, congrats to the team on shipping it! ), we understand that turning off the flag did resolve the issue. We will be happy to troubleshoot if you point us to some documentation about the "discovery" process for the public directory in your comment. Thanks again.
Thanks for confirming the issue! No need for you to do anymore work — I'll fix this upstream so once DEV_SSR is enabled for everyone, it won't cause you (and others with similar setups) to have any trouble.

Discussion:
: '/' + clientLocale; module.exports = { <ins> flags: { DEV_SSR: false }, </ins> siteMetadata: { title: 'freeCodeCamp', siteUrl: homeLocation