Facing Issue related to completing challenges. Getting something went wrong error.

[chethanbhat]

Issue Description

Not able to go to next challenge or visit challenges in map.

Map is totally unresponsive. Cannot visit any links. Cannot complete and go to next challengesas well by pressing Ctrl-Enter or Clicking Modal.

I get Something went wrong error everytime. Attached screenshots for better understanding.

Browser Information

• Browser Name, Version: Firefox - 58.0b7 (64-bit), Chrome - 63.0.3239.132 (Official Build) (64-bit)
• Operating System: Ubuntu 17.10, 64bit
• Mobile, Desktop, or Tablet: Desktop

Screenshot

[Asjas]

Hi @chethanbhat

I reported the same problem in Issue #16433. I am also "stuck" and cannot move through the map. I also tried to clear my Freecodecamp progress but it seems even that fails with a Something went wrong, please try again later.

[chethanbhat]

Hi @Asjas

Its really frustrating. Everyday i think of making some progress but not able to do so. Hope fcc teams fixes this !

[raisedadead]

Hi @chethanbhat @Asjas thanks for reporting,

As you maybe aware, we are ironing out issues on the beta platform.
While, we do that the beta website will be unstable, as a consequence.

You are more, than welcome to try out the platform, but please bear with us as the instability is expected.

Happy coding!

[dhuber666]

Hi I have the exact same problem.
Another thing I found out in the Chrome Debugger Console.
Every time I click on Submit and go to next challenge, I get this error in Console:

TypeError: Cannot read property 'challenges' of undefined

The specific link I found this bug:
https://beta.freecodecamp.org/en/challenges/redux/handle-an-action-in-the-store

Screenshot:

Question:

As a beginner I don't mind trying to find the root of this bug. I can debug this if I fork the repo and try this out on a local server because in the uncompiled version I see the js file which is causing the error right? Because right now I just see the bundle.js file that is not useful for me at all, right?

[raisedadead]

Update:

We have merged a couple of changes and these should make the platform much stable and usable.
Hopefully we will be deploying them on beta, in a couple days.

Thanks for your patience again.

[LiteSoul]

The issue still persists! So it should be an open issue

[Asjas]

@LiteSoul Both issues are open. No-one has closed either issue

[kdesCode]

Hi All
Agreed still seems to be an issue.
Get the same error. Base in South Africa.
Interestingly on a 4Mbps Fiber connection i get the issue. On a 10Mbps +- 3G connection i do not get the message. Perhaps some sort of time out setting some where not allow lower bandwidth connections to download all. Just a guess.

[raisedadead]

Hi @BerkeleyTrue @Bouncey

From what I understand the only way to cleanly get around this is to have a pre-loading animation while the bundle is available.

The issue, is that actions done while the bundle is in flight, break due to the RX pipeline. I am not an expert, so do not have a pin point cause. And this subsequently results in the exception being thrown. Post which everything is blocked.

What I mean is that that if we let the intial download / render go through without any interuption, our app performs much better.

Now, I am not saying we should ignore the underlying errors in anyway. They should be fixed.
But, I think one way to go would be to not perform actions while the app is not ready by adding a overlay loading animation of some sort.

Berkeley's previous fix, on reducing and lazy loading seems to have improved this performance quite good, but, I am afraid even with CDN, a majority of user's behind slow networks (average 3G like speeds) or VPNs are still needing quite a bit before the bundle is available.

I would love some thoughts on the approach here?

[BerkeleyTrue]

@raisedadead I'm going to add source maps to beta so we can pinpoint where the error is happening. Hopefully we can find it without having to resort to loading icons, which would remove all the work we are doing make ssr happen.

[BerkeleyTrue]

Testing locally it appears the first initial error (the xhr timeout) is the map service.

This is most likely leading to the other errors but I'm not able to replicate. Adding source maps should help illuminate the problem. The map is definitely a problem, since we've added so many challenges it has ballooned up to several hundred challenges in dozens of blocks. We'll need to optimize this before beta launch.

A possible solution is to make this a static file but this has the draw back of needed to build for every updated.

I know this is something that could be solved with graphql, but I'd rather not add more complexity (moving the goal post) to an already hugely delayed project.

I'm open to other suggestions as well.

cc @Bouncey

[Bouncey]

How about splitting the map service into two separate services.

• map service: provides data for rendering the map UI only
• challenge service: provides data relevant to the current block/superblock only. Provides other blocks/superblocks on request. I.e the user finishes a block and moves on to the next block. Logic for this could be when executing a challenge, check to see if the current challenge is the last in the current block. If so, request the next block in anticipation

[BerkeleyTrue]

That could be done, the map service would just deliver the map tree. We then use the rest api (which has limit/skip) to get the rest of the information. This would add some complexity but it wouldn't be so bad.

[Bouncey]

@BerkeleyTrue

Would you even need to skip/limit?

We could just request by block name. If my current challenge is in the ES6 block, I don't need the redux block, or any of the others. Only the ES6 block.

If I click on a challenge outside of my block and the data is not in the store, I could have a loader rendered while the challenge service brings me the data for that block.

We could even take it as far as caching the blocks in local storage, but that would be down the line

[BerkeleyTrue]

We could just pull a block and all it's challenges, but keep in mind that some blocks have dozens of challenges.

[Bouncey]

That's what I was trying to say. One block's worth of challenges in a single payload is a lot lighter than all of the challenges from every block. If the user doesn't need it right away, we shouldn't send it.

[BerkeleyTrue]

Agreed

[kdesCode]

I am no expert and know very little. Just started the journey to learn all this.
But just another guess, is there no where one can change the timeout limit? Perhaps make it higher to allow lower bandwidth connections time to download.

[Bouncey]

@kdesCode Whilst that would help in alot of cases, the simple fact is we are sending around 6MB of challenge data to everyone, even when they don't need it. The fix suggested is to send selected chunks of challenges that are relevent to the user.

This will reduce the amount to be downloaded, which will have the side effect of reducing the time required for the request to complete.

[jsonkao]

The direction of this issue's discussion is apparent: Apollo client with GraphQL/Express server. This is just something I wanted to propose, but a migration would definitely delay the release greatly.

[LiteSoul]

Well, anything is better that the current state which is virtually unusable.
Me learning GraphQL is just months away, sorry I can't contribute right now... but maybe Bouncey suggestion is simpler

[Bouncey]

@BerkeleyTrue

[raisedadead]

Sweeeet!

[jsonkao]

Amazing! If you need any help with Apollo I'm down

[LiteSoul]

@chethanbhat , @dhuber666 , @kdesCode do you still experience the issue? It may have been fixed. I have it sometimes, but not all the time.

[Bouncey]

Cross-posting so that you can still keep working on the challenges until we get this fixed

What you could do to keep the challenges coming is navigate directly to the challenges themselves. Hovering over the challenge in the map will show you the address of the next challenge.

I know this is not ideal, I should have a PR ready today.