node-cron: Error: Something went wrong. cron reached maximum iterations.

Context: I was interested in finding a way to reproduce the high server load situation to make the tests fail on purpose, enabling debugging the issue and opening the way to find a solution to this issue (when caused by server load).

I tried running tests with very limited resources (to simulate the server being under high load), and as expected this error was thrown multiple times (on 11 tests out of 125 total).

Command used to run the tests: systemd-run --scope -p MemoryMax=64M -p MemoryHigh=52M -p CPUQuota=1% --user npm run test

List of all the tests that failed

• crontime › should generate the right next days when cron is set to every 15 min
• crontime › should work around time zone changes that shifts time back (1)
• crontime › should work around time zone changes that shifts time forward
• crontime › Should schedule jobs inside time zone changes that shifts time forward to the end of the shift, for weekly jobs
• crontime › Should schedule jobs inside time zone changes that shifts the time forward to the end of the shift, for daily jobs
• crontime › Should schedule jobs inside time zone changes that shifts the time forward to the end of the shift, for hourly jobs
• crontime › should generate the right N next days for * * * * *
• crontime › should generate the right N next days for 0 0 9 * * *
• crontime › should generate the right N next days for 0 0 * * * with a time zone
• crontime › should generate the right N next days for */3 * * * * with a time zone
• crontime › should test valid range of months (*/15 * * 6-11 *)

---

---

Hey there! As stated above, we released a fix for this issue in v2.4.1 🎉

We expect this change to fix the majority of cases you encountered, which we believe were mostly related to low resources environments.

Please update to that version, and open a new issue if you encounter a similar issue again (if no one opened one already).

nice! I wonder if there’s a way to detect high system load a little better than just our own app taking a long time and then notify the user of that issue. previously a soft failure was considered which I feel is better than our app forcing a crash. that leaves room for recovery and hopefully successful execution of future jobs. as long as we notify the user that there was a failure and as long as we can “catch up” once there are more resources I would prefer that

No, the error is still there, and every time it gets stuck here and then reports the error [92%] sealing (asset processing TerserPlugin)

We just add this issue overnight with code both in prod and that could be reproduced in local. The same code was running fine previously. Commenting one the call solved the issue.

(note: we are using “@nestjs/schedule”: “^2.2.0” which is using “cron”: “2.2.0”)

And the crash disappeared by itself… might be related to hour change in my region…

what exactly about that function needs to be changed?

• The infinite loop can be refactored. Incrementing every moment passing while relying on “This took way too long” can surely be done another way.
• All the complexity needs to be removed in favour of a robust clear technique.
• Most of these issues arise from this complexity and not being able to reliably calculate when the next cron run should be.

This can’t really be fixed without a major refactor.

Take a look at _getNextDateFrom