Change:
// eval test string to actual JavaScript // This return can be a function // i.e. function() { assert(true, 'happy coding'); } <del> // eslint-disable-next-line no-eval const test = eval(testString); </del> <ins> const testPromise = new Promise((resolve, reject) => // To avoid race conditions, we have to run the test in a final // document ready: $(() => { try { // eslint-disable-next-line no-eval const test = eval(testString); resolve({ test }); } catch (err) { reject({ err }); } }) ); const { test, err } = await testPromise; if (err) throw err; </ins> if (typeof test === 'function') { await test(e.getUserInput); }

Discussion:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --Describe your problem and how to reproduce it: your code 'Run the Tests' it passes all your tests, again click on 'Run the Tests' time, it will show an error. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: 83.0.4103.61 Operating System: Windows 10 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): 1st-time click on 'Run the Tests' ! 2nd-time click on 'Run the Tests ' ! I would love to work on it. Please assign it to me Thank You
Hello there, This issue has been discussed on: And, if you are passing the tests, and returning to fail, it is not much of an issue. So, I will leave the same comment as I did in the forum: To solve, refresh the page. Perhaps, it might be useful to some, if the tests and seed code were rewritten, but refreshing the page, and ensuring the code is correct is a suitable fix. I will leave this issue open, but, seeing as this challenge has existed for a long time, this issue rarely arises, and the workaround is as simple as refreshing, I do not recommend a PR be opened for this.
Okay
While I agree that this isn't the highest priority (as there is a work around), it's still a bug. Someone should not have to refresh the page to reliably pass the tests. That said, it might not be easy to fix. It's possibly a case of re-writing the tests to be async and ing in the tests, but I'm not sure.
I believe this should be fixed with the following assert:
Unfortunately not, since that is basically which passes. needs to return an async function.
oh yeah, you are right, my bad. what about enclosing the assert inside the method?
I am unable to reproduce this locally. Is there a chance that there is some cache reason for this behaviour?
Yes it cant be reproduced locally. I dont think its a cache issue.

I believe the latency is too less - the document is loaded instantly whereas the actual environment is slower so we are able to get the mentioned behavior.
I am curious as to what's going on here. My suspicion is that it's a timing issue, that for some runs the test gets evaluated before , but I'm not sure. Since document ready is asynchronous, the assert will be called at some point after the test has already passed. Take a look here: you can see if the test throws during the initial (synchronous) evaluation, the error is caught and the test fails. If instead it doesn't throw and returns a function, then that function should return a Promise. Finally that Promise is ed. If it doesn't throw, then the whole thing passes. The formulation you're talking about won't throw during the first evaluation and does not return a function to be awaited. It should (I think) always pass.
Given that this has been reported for several challenges, I think it's reasonable to assume that all the challenges that rely on could have the problem.
agreed. It would be interesting to figure out a fix for this. I will try on my end but I hope other contributors are actively looking for ways to resolve this.
Yep, it would be good to understand why this is happening. That may not be easy to discover, though, so I'd be happy with a PR that just modifies the tests to wait for .
Some observations: I have Disable Cache turned on under the network tab it always works for me. If I disable it, I can make the tests reliably fail. long as all the files have 0ms delay (memory cache) the test fails, the minute a vendors~chai js file has just a 1ms delay it passes the test (disk cache vs memory cache), . two challenges that are not using jQuery for the assert tests always pass for me. Not sure if it's simply the DOM querying that is the issue, or jQuery itself. How is the browser cache locally disabled? It always does a network fetch and is never fetching from disk or memory. Can that be disabled? As far as I can tell because there is always a fetch delay locally the tests never fail. Which makes it hard to test.
Nice QAing Presumably that tiny delay is enough for all the changes to appear in the DOM. Good question.

I tried building the site () and serving it using , but it's still not cached. It might be getting cached when you use .org because of the cdn, but I'm not sure. If that's right, it's something that we will have to deploy to test.
I'm pretty sure this is now fixed on .dev - I can no longer reproduce the problem. could take a quick look and confirm/deny?
Nice job, all the jQuery challenges pass for me now. Ran all of them in Chrome and a few in Firefox. Passed first try every time. :+1:
Nice. Thanks for all your help. Looks like we've got to the bottom of it.