Comment éviter les tâches qui se chevauchent ? DistributedMutex ?

Nouveau venu dans les plugins. J’essaie d’adapter un plugin qui prend environ une heure à s’exécuter. En regardant /sidekiq, je vois que le job s’exécute toutes les 30 minutes. Ainsi, avant que le premier job ne soit terminé, une autre instance du même job démarre, créant des résultats en double. Comment puis-je empêcher cela ?

Une option, bien sûr, serait de faire en sorte que le job s’exécute dans ses 30 minutes autorisées, mais il existe d’autres contraintes, et je préférerais le laisser s’exécuter aussi longtemps qu’il le souhaite.

J’ai essayé ceci, mais cela ne semble pas empêcher une seconde instance du job de s’exécuter :

DistributedMutex.synchronize("custom_digest", validity: 180.minutes)

Je pense que le job d’e-mail de résumé effectue ce test, qui a été ajouté au début de cette année. Vous pourriez jeter un coup d’œil là-dessus.

Je pense que je fais la même chose que https://review.discourse.org/t/feature-allow-post-process-mutex-to-be-held-longer/5017 et https://review.discourse.org/t/fix-post-and-topic-creation-race-condition/5247, à l’exception de l’utilisation de accolades plutôt que de do/end, mais je ne pense pas que cela ait d’importance.

DistributedMutex.synchronize(“custom_digest”, validity: 180.minutes) {
do_stuff
}

Pourtant, do_stuff s’exécute plusieurs fois en parallèle, et ce bien avant la fin des 180 minutes.

Si le mutex se trouve dans le bloc execute, cela signifie simplement qu’il bloquera à cet endroit en l’attendant, ce qui implique que vous verrez deux tâches s’exécuter : l’une en cours d’exécution et l’autre en attente du mutex.

Peut-être souhaitez-vous vérifier sa présence et retourner immédiatement s’il existe une autre instance en cours d’exécution ? Il est difficile de deviner avec si peu d’informations sur le cas d’utilisation exact.