L’heure était 9h44 et cela a été fait 14 heures plus tôt. La prochaine tentative serait 10 heures plus tard, ce qui signifie environ 19h44. Je m’attendais à ce que ce soit assez tôt après minuit et une fois par an, comme le ferait cron.
Le travail est programmé pour s’exécuter une fois toutes les 24 heures pour le mois de janvier : discourse-yearly-review/app/jobs/yearly_review.rb at main · discourse/discourse-yearly-review · GitHub. Si un sujet est trouvé sur le site dont le titre correspond au titre du sujet de révision, le travail ne sera pas réexécuté. Cela signifie qu’un seul sujet de révision sera généré, à moins que vous ne modifiiez le titre du sujet de révision après sa création.
Est-ce que 31 fois jusqu’à ce qu’un sujet approprié soit trouvé est une sorte de mécanisme de sécurité ? Ou avons-nous une barrière linguistique ici ? Les chances sont élevées pour cela aussi :rofl :
Mais… je ne comprends toujours pas les horodatages. Le 1er janvier à 9h44, sidekiq indique que YearlyReview a été déclenché 14 heures plus tôt, le 31 décembre.
Encore une fois, ce n’est absolument pas un problème. J’essaie juste de comprendre, car j’ai trop de temps libre.
Mes utilisateurs seraient assez anxieux s’ils devaient attendre encore 10 heures pour obtenir ces précieuses statistiques. Eh bien, je sais comment relancer sidekick, donc le problème est résolu
Oui, il est là pour empêcher que la tâche ne soit accidentellement exécutée en dehors du premier mois de l’année. Notez que si vous déclenchez la tâche depuis la console avec l’argument force: true, des sujets d’examen peuvent être créés en dehors du premier mois.
Est-ce vraiment nécessaire ? J’ai dû supprimer des sujets en double et désactiver le plugin sur quelques-unes de mes instances. Ce n’est pas un problème majeur, mais cela semble injustifié.
Pendant le Nouvel An, les administrateurs sont souvent absents de leurs instances pendant plusieurs jours - s’ils n’ont pas dirigé le plugin vers une catégorie privée agréable et restreinte, ce n’est pas idéal.