How would you reproduce this problem?

Just experienced this after months of no issues. 2 different apps, each on 2 servers, so 4 instances all stopped running at the same time. Was after a momentary database disconnect but we've had disconnects before and the cron continued running after the db came back. Wonder if something got in a weird state in the database...

Restarting the apps fixed the issue.

Looking at it I think maybe the database disconnected when writing of the result of the cron, and it seems cron doesn't run again if the previous run didn't finish, so that would make sense.

Experiencing the same issue after a database disconnect

this sounds quite scary for a production-app - has there been a fix for this issue?

@thebarty @MathiasVandePol @mjmasn @MichaelJCole @orangewise
If the database disconnected when writing of the result of the cron, then setInterval throw exception and not run any next jobs.

I created pull-request for this

@MichalW @MathiasVandePol @mjmasn @orangewise I'm experiencing 2 of my 4 jobs no longer running on their schedules (randomly) after ~months of good operation. The two that are running happily all the time are:
return parser.text('every 40 mins');
The two that suddenly stop every few months are:
return parser.text('at 1:00 pm');

Does this sound like what y'all are experiencing?

I'm not experiencing issues with "every 31 minutes" as the interval.

Thanks for getting back, @MichaelJCole. This issue does seem to be intermittent; I only have the problem randomly after weeks or months. But when it does happen, my SyncedCrons just stop running.

It seems there is a patch ready here #112 - which @MichalW reviewed. Any idea if it will help/are there any blocks to accepting the pull?

When will this patch be released?

plus 1 for getting this in

Hi all, I haven't had a problem since moving all my parsers to parser.cron('') - has that method broken for anyone else?

@paolo-g two things:

1. This issue is fixed as of release 1.3.1 as far as I know
2. Can't say for sure but if you're on a pre 1.3.1 release I think you probably just got lucky, the issue was that any mongo failure that threw an error would prevent the next run from being scheduled because there was no try/catch wrapper. I don't think parser.cron works in any fundamentally different way to parser.text (they both return a schedules object).

Bumping this because I think I'm experiencing the same issue. I noticed that my cron jobs weren't running and when I looked at the logs I saw that the mongo connection had timed out. I'm using 1.3.2 so theoretically this problem should be fixed. Anyone know what's going on?

I'm still getting this problem. Just me? I'm already on 1.3.2

I would like to fix this problem but I don't know what is the root cause since this problem with mongo seems to be fixed as commented above.

Any idea @TheGame2500?

The database stopped at 20

Is now 2020, I used the version 1.5.1, seem to have the same problem, because the mongo database server in 20 points yesterday because the CPU is 100%, stop the service, lead to stop running the cron, until I found this morning, after restart the meteor application, to return to normal, I want to know, how to solve this problem, now I use a parser. The text (' every 1 mins'), the parser. The text method

Does anyone have a solution to this problem? If so, please let me know. Thank you very much

@filipenevola Have you solved this problem? I see that you posted the problem at least half a year ago, I hope to get your help

@paolo-g Do you mean changing parser.text() to parser.cron() will solve the problem?

Hi @eugle , I'm not having this problem anymore. I just migrated to littledata:synced-cron

@filipenevola thanks，There is no problem for the moment. We will observe it later