Problem with FCC projects in Replit - Projects hang after testing

I believe there is something wrong with the FCC projects on replit. I’ve completed my Stock Price Checker project locally and it works great, even passes all the tests on the submission page, but it was local. I cloned the boilerplate to Replit, copied over my code, and again it works great, all my Chai tests pass, but after the Chai tests run, the page hangs, all requests time out, and the frontend web page goes to a replit page saying:

# Hmm... We couldn't reach this Repl
## Make sure this Repl has a port open and is ready to receive HTTP traffic.

The app is still running, and didn’t generate any errors, just saying all tests passed. If I disable the tests, the page works fine, and I can send and receive requests, all functioning perfectly. Turn the tests back on, and it comes up, but as the tests finish running, the page switches to the replit error, and things hang. Troubleshooting on my end couldn’t find any issues, and nothing relevant on Replit I could find.

I decided to try some of my older projects that worked previously, and they now do the same thing. I tried Sudoku solver, metricimpconverter, mochachai, issue tracker, and each of those do the same thing now, come up, pass tests, then the page hangs with the replit page, although any zombie browser tests fail as the timeouts now prevent them from working.

Could someone else try some of there old FCC projects that have functional tests on Replit to see if the problem is not just on my end? Any ideas what might be the issue?

My Replit

3 Likes

This is a persistent issue with running QA tests in FCC projects on replit. Other people understand the issue better than me but I don’t think anyone has yet come up with a fix for it. If it’s a case of trying to pass FCC tests, the only workaround that I know of is to submit the project link to FCC just as the QA tests are running, but before the repl has a chance to crash.

1 Like

Yeah, I’ve had to race the tests on previous project submissions before, but have never had it do it so consistently. Before it seemed like random timeouts, but now seems more heavy handed… like a program interaction. It also now does it without fail on all my previous projects, which I had used previously without issue.

I couldn’t manage to walk away and wait for an answer, so I’ve been working the problem. I’ve isolated it to the functional tests, in particulary, the “.end” part of the Chai request. If you take that out, it won’t hang, but it also won’t pass… if you leave it in, it hangs, everytime.

Being able to be more specific in my searches, I finally found this stackoverflow, from like a year ago:

It doesn’t give a clean solution but does conclude that it’s the .end causing the issue…that the final .end is instructing Replit to close its ports or something. Its recommended work around is to put in an after chai request that sends a request, but doesn’t .end it… I put this at the end of my test suite, and it works to keep my page running after the tests are complete.

after(function() {
  chai.request(server)
    .get('/api')
  });

Now my program runs without issue. I guess that’s a simple workaround answer.

Someone official may want to look into this as all my Replits do this without fail now… something has changed, either an updated software, or a policy or settings change.

I’m still curious if anybody else is now consistantly having this issue, or just me, but for someone just starting out with like the initial Mocha test Replit, I don’t see how they are expected to pass the projects now without hitting this problem, and will probably knock some people completely off the path.

2 Likes

Although I will add, occationally I do get timeouts on some of my tests because Replit is running exceptionally slow today, and the page refreshes itself between each test… seams each .end causes a disconnect, then the next chai test causes it to reconnect.

Hadn’t tried Glitch yet. Used Heroku for a few projects previously… but I’m sure their going pay-only hurt everyone. I mainly program locally(vscode), then once all is good, click the Replit starter project link and copy my code over. Usually not a big deal, but I believe something has changed.

That work around was pretty successful and I submitted my project, so not a huge issue for me anymore, but I do worry others will have probs. I read something about a .keepOpen() option that might hold the connection open between tests… figure whoever wrote or maintains the original Chai Replit test module could probably find a way to prevent these issues once the cause was identified.

I may try Glitch for my next project, not out of necessity, but always interested in getting experience with more tools. Thanks for the suggestion.

Quick question, just became aware of gitpod… does anyone know if that’s a viable option for hosting and submitting FCC projects?

As far as I know, you should be able to use Gitpod. If you pin the workspace it shouldn’t get deleted and I think the live URL persists (remains the same). So that might be an option.


Side rant.

The requirement of a live URL is honestly a bit questionable. There are plenty of projects that have passed the tests and were submitted as a solution that is not functional anymore.

Pretty much any project that uses MongoDB Atlas will have the cluster paused after some amount of time and as a result, the project is not functional and can’t be easily checked. Depending on where and how the project is hosted checking it might be impossible.

It would be just as easy, if not easier if the project submission was a GitHub repo. At least then you would have guaranteed access to the source code.

Well, yeah, my mongo had to be unpaused a few times. I’m sure it wasn’t expected that the link work forever, but figured they’d want to verify the certification sometime within a week or so after the posting… not sure if anyone is actually doing that. They also give the option to post a github link which I’ve been doing as well.

I’m almost finished with the next project. I’m going to post it on replit, and I’m trying out a new solution for the functional tests.

Found something saying you can specify for Chai to leave the testing connection open by specifying .keepOpen after opening the request. It says it will then keep the server connection open, supposedly to help if you’re running multiple tests, until you manually close it. I’m curious if that’s going to prevent it from knocking the server offline.

After I’m finished with that, if it works I’m going to post a solution to this thread regarding either using keepOpen, or using that after workaround so future gens can find and easily get around that glitch…I’ve wasted days while learning, troubleshooting my code assuming I was doing something wrong when instead it was just Replit and Chai not playing well together.

1 Like

I was also suffering from the same phenomenon, but as a result of checking the operation many times, chai seems to stop the server when the functional test ends.

FCC Test, which follows, will probably fail because the server is already down.

As a solution, how about using “keepOpen()” like the code below to prevent chai from killing the server?

Github : GitHub - Makoto-Araki/boilerplate-project-stockchecker: A boilerplate for a freeCodeCamp project.

suite('Functional Tests', function() {
  test('Viewing one stock', function(done) {
    chai
      .request(server)
      .keepOpen()  // add
      .get('/api/stock-prices')
      .query({ stock: 'AAPL' })
      .end(function(err, res) {
        ...
        done();
      });
  });
  test('Viewing one stock and liking it', function(done) {
    chai
      .request(server)
      .keepOpen()  // add
      .get('/api/stock-prices')
      .query({ stock: 'AAPL', like: 'true' })
      .end(function(err, res) {
        ...
        done();
      });
  });
  ...
});
1 Like

Yeah, finished the Message Board project today, and surprisingly enough, it did not have any issues running the functional tests… but all my older projects including the Stock Checker did. I bet there is a difference in versions or something between those two projects.

But I did go back to the older failing projects, and tried the .keepOpen() and sadly it did not help. My application still froze even with that added. But confirmed again that adding an after statement with an open-ended get request does bring your project back online.

Well, didn’t find a reason or solution to the problem, but below is a work around that worked for me to prevent my project from hanging after the tests run.

suite('Functional Tests', function () {

    // put this in your functional test suite
    after(function() {
        chai.request(server).get('/api')
    });

    //--- Rest of your suite and test declarations ---
}

Theoretically sometimes the .end of the chai tests is stopping the server from listening for additional request. The after runs when your tests are complete and the open-ended request will keep chai from disconnecting your app afterward. Then you can submit to FCC without issue.

NOTE: I don’t know if there would be any negative effects from doing the above, so I guess use at your own risk.

2 Likes

Thank you. I had exactly the same issue on the Issue Tracker challenge and this seems to have resolved it.

Hi! Thanks for bringing this up. I had the same issue. Both in Quality Assurance Issue Tracker and Personal Library. I found a way to use keepOpen(). Before all the tests we can create a superagent object bound to the server instance, using keepOpen() and put it in a variable (e.g. agent), which will be used in each test instead of chai.request(server). Here is a code snippet from a test file:

const agent = chai.request.agent(server).keepOpen();

suite('Functional Tests', function() {


  suite('Routing tests', function() {


    suite('POST /api/books with title => create book object/expect book object', function() {
      
      test('Test POST /api/books with title', function(done) {
        agent
      .post('/api/books')
      .send({title: "test title"})
      .end(function(err, res){
        assert.equal(res.status, 200);
        assert.equal(res.body.title, 'test title', 'the book should contain given title');
        assert.property(res.body, '_id', 'the book should contain _id');
        done();
      });
      });
1 Like

Thank you kinome79, your solution worked brilliantly.

My replit RAM meter is no longer having a nuclear meltdown!

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.