Dear All,
I am having trouble to Run a test.
It always comes with the same error - Your tests timed out.
I did couple of times - Revert to exercise start but it still returns the same error.
Could you please advise ?
Thank you.
1 Like
I’m also getting a timeout on everything.
1 Like
Is it only timing out on this exercise or all exercises on the js track? Does it timeout when working with the CLI?
I encountered the same problem in C sharp.
It’s likely we’re hitting IOPS limits as we (@Cool-Katt and I) merged a ton of changes the past few days, causing a lot of retesting.
We are very close to solving this by moving tests to the browser @AngelaHiss and @Liene31 .
For now:
- Apologies. This is an infrastructure issue out of our hands, but caused by us.
- If you are feeling adventurous you can try to solve the exercise locally using the CLI. Then at least you know if the tests pass or not.
- I will post in this thread when the browser test-runner is live.
3 Likes
Thanks for the update.
Trying to work my way out using the CLI. 
Liene
2 Likes
my tests in javascript are timing out too. can’t wait for the browser test-runner @SleeplessByte mentioned! Anyone know that time scale for the fix? today, this week, this month?
I’ve been testing it for the past week. Wrote it two weeks ago.
Should be good to go very soon 
3 Likes
Está acontencendo comigo também.
Others have mentioned the “Tests timing out” being due to a DDoS attack - is it actually just the infrastructure problem you’ve mentioned?
Also - I’ve submitted via CLI while it’s down, but it looks like it’s stuck trying to “process” it on the exercise page - is it ok to mark it as complete and move on or will the submission be lost?
See 🚨 Tests timing out? Read this
@Leonod33 you can continue, your submission will not be lost. What happens here is that even when you submit via CLI, the tests “time out”. It should periodically try again. You can safely continue.
More information:
We have a < 30s window to complete the tests, but one of the many challenges is “disk operation resources”.
Tracks such as JavaScript have the “node module” issue, where it requires a lot of resources to have a project with test runner etc. Because of some rather weird architecture choices in jest, we need all the dependencies to be local to your solution. That means moving (or symlinking) a lot of files.
Amazon has two resources that constrain us. Disk IOPS and for some things we used to use (dunno if still true) burstable performance instances. Both of these things can drain, and then everything becomes slow. But when things become slow, we can no longer hit the 30s window.
Solutions
- More money buys better hardware, so more people donating helps.
- Heavier caching of resources. Jeremy (Mr. Exercism himself) is working on this. This will help a lot.
- Blocking malicious requests. This has been improved and helped quite a bit (~20%).
- Tracks having a in-browser test runner. I have written one for JavaScript which I have tested for the past 2 weeks. It will go live very very soon.
1 Like
It’s a result of mitigations against being DDOS’d.
2 Likes
Issue Resolved: My tests are running this morning.
1 Like