-
Notifications
You must be signed in to change notification settings - Fork 622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: Something went wrong. cron reached maximum iterations #478
Comments
yes, it reappeared, though solved in cron@1.8.2
|
Same. I am also using cron@1.8.2. |
I realized the error would show whenever my CPU utilization is too high (>9x%). That might cause some delay of code and affect something. |
agree, happens when load goes high |
Same for me, using @1.8.2 |
Happens to me too, |
Happens to me too, |
Yes, got this error too after some time after upgrade to 1.8. Before it version 1.7 worked perfectly over more one year on different installations. |
Thinking (but not tested) it related to this commit: Reverted back to 1.7.2 for now. |
Maybe with
|
I have the same problem, any fix for that? |
Revert to 1.7.2 for now. For me 1.7.2 was bugless. |
How does one upgrade from 1.5? On docker hub for NodeRed/node-red docker images i can’t see anything tagged 1.7 |
@mar005 this issue is related to the cron module and the discussions around version numbers related to the cron module, not the version of any application that is using the cron module internally. |
Ah ok thank you for clarifying. How would I go about finding or applying this workaround then? Apologies for not knowing. |
I'm curious about this because it is obviously affecting a bunch of projects. If it's truly due to cpu load, then can that cpu load be reduced/offloaded, or the jobs placed on a different machine? Would you rather the job run even if the task execution is a little fuzzy? For instance, would it be better to have an option to say @rusekr what makes you suspect the commit you pointed to? The biggest change there is that rather than having an additional timer running, we just grab the time before the while loop and then just check against the current time. It's possible that in the prior cases, when cpu load was high, the timeout was affected and caused that timeout to delay as well. This makes the execution a little more strict. @knolleary cool project. :) |
@ncb000gt From my perspective - used this module in production high load systems since 2016 and not got critical (uncatchable?) error even once and this module worked like a charm. No need to catch this errors and handle this. Now after not major and not breaking update of this module my projects start to crash and you suggest me update hardware on all my (future) productions to what specs? Place additional monitoring, restart handlers? Patch on all projects such type of minor error that can be a just warning (where to place the handlers?)? It's rediculous. For commit - you answered yourself - it was only commit from 1.7.2 to current version that changed related to error behaviour. Therefore was my suggestion of cause. |
And not mention causes - it for now is bug. If it can't be reverted or fixed suggesting 2.0.0 version of component with breaking changes and example of catching and handling such error. |
Happening to me as well: v1.8.2
[Edit] |
I pushed up a PR with some changes to allow a "soft warning". Can you please test and report back? |
Great PR - it converts bug to feature, but if default for softTimeout is false - it is breaking change (with main commit caused this issue). And after upgrade to newer versions people must add this config in all cronjobs. Meanwhile - even with softTimeout turned on this warning may occur in between server syncing time with ntp or changin from/to dst. Fot this js now have: https://developer.mozilla.org/en-US/docs/Web/API/Performance/now and some examples https://developers.google.com/web/updates/2012/08/When-milliseconds-are-not-enough-performance-now May be use this instead? |
Yea. I hear you re: still occurring. This pr is to hopefully allow the developer to make the decision at to whether ms precision is necessary or not rather than throwing an exception. I can take care of the warning showing at all later. Thanks for the docs. As for the first point, re: default of false. I think you're right. I'll default it to true. |
This comment was marked as spam.
This comment was marked as spam.
closing in favor of #467 |
Time Zone: "" - Cron String: 0 0,30 * * * * - UTC offset: +00:00 - current Date: Mon Mar 16 2020 16:31:21 GMT+0000
cron@1.8.2
@types/cron@1.7.2
stacktrace:
index.ts:
The text was updated successfully, but these errors were encountered: