Le dernier cas de sélection de batch suppose qu'on peut fetch le check correspondant au last_check renseigné.
En cas de bug (ou perte d'historique ou autre), on peut avoir un last_check qui est un id de check qui n'existe plus dans la table checks.
Les checks sont en effet purgés au bout d'un temps.
Dans ce cas, la ressource ne sera plus jamais crawlée car non retournée à cause de AND catalog.last_check = checks.id. Il faudrait prendre en compte ces ressources si elles référencent un check disparu depuis.
Il est aussi possible de supprimer le last_check dans le cas de purge d'un check, mais il existe la possibilité de supprimer ponctuellement un check dans la db et donc le risque d'avoir un last_check inexistant.
Commande run manuellement en prod en attente de fix :
hydra-hydra=> UPDATE catalog SET last_check = NULL WHERE catalog.last_check NOT IN (SELECT id FROM checks) AND deleted = false;
UPDATE 20351
Le dernier cas de sélection de batch suppose qu'on peut fetch le check correspondant au
last_check
renseigné. En cas de bug (ou perte d'historique ou autre), on peut avoir unlast_check
qui est un id de check qui n'existe plus dans la tablechecks
. Les checks sont en effet purgés au bout d'un temps.Dans ce cas, la ressource ne sera plus jamais crawlée car non retournée à cause de
AND catalog.last_check = checks.id
. Il faudrait prendre en compte ces ressources si elles référencent un check disparu depuis.Il est aussi possible de supprimer le
last_check
dans le cas de purge d'un check, mais il existe la possibilité de supprimer ponctuellement un check dans la db et donc le risque d'avoir unlast_check
inexistant.Commande run manuellement en prod en attente de fix :