This is very cosmetic one and I’m just curious, but
Jobs::YearlyReview really timed to run twice every dayThe time was 9:44 AM and was done 14 hours earlier. Next try would be 10 hours later meaning something like 7:44 PM. I expected quite soon after midnight and once a year as cron would work.
The job is scheduled to run once every 24 hours for the month of January: discourse-yearly-review/app/jobs/yearly_review.rb at main · discourse/discourse-yearly-review · GitHub. If a topic is found on the site that has a title that matches the review topic’s title, the job will not be re-run. That means that only 1 review topic will be generated, unless you edit the title of the review topic after it is created.
Is that 31 times until proper topic is found somekind of fail safe? Or do we have a language barrier here? Odds are high for that too 
But… I still doesn’t understand timestamps. At 9.44 jan 1st sidekiq tells YearlyReview has been triggered 14 hours earlier, dec 31.
Again — this is not an issue whatsoever. I’m just trying to understand, because I have too much free time.
My users would be quite anxious if they should wait 10 more hours to get those precious statics, though. Well, I know how to kick sidekick, so problem solved 
Yes, it is there to prevent the job from being accidentally run outside of the first month of the year. Note that if you trigger the job from the console with the force: true argument, review topics can be created outside of the first month.
Is it really needed? I’ve had to go and delete duplicate topics and turn the plugin off on a couple of my instances. This is no massive deal, but seems unwarranted.
Over New Year’s, admins are often away from their instances for several days - if they haven’t directed the plugin to a nice, tight private category that isn’t ideal.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
