Transport.Jobs.Workflow : gérer Oban.TimeoutError

[AntoineAugusti]

Symptômes du bug décrits dans #4406 et oban-bg/oban#1210 en détails.

Les jobs de la queue workflow ne sont pas exécutés et en regardant en console il y a des jobs qui sont dans des états incohérents entre la console de production et la base de données.

Il se trouve que quand un Transport.Jobs.Workflow exécute un job avec un timeout et que cette situation se produit, la payload reçue par le handler Telemetry n'était pas bien gérée oban-bg/oban#1210 (comment). La documentation d'Oban est perfectible pour les événements oban-bg/oban#1153 (comment)

Ceci empêche le job Workflow de se mettre à jour : retry ou discarded. Le job reste en executing pendant plus de 60 minutes et se fait donc remettre en available par le plugin Lifeline oban-bg/oban#1210 (comment).

On ne s'attendait pas à avoir une struct dans ce bout de code, ce qui cause le problème. Un crash dans un handler se voit mal, remonte mal (pas du tout même ?) dans Sentry (identifié dans #3454 précédemment). Bref, difficile à voir.

[AntoineAugusti]

Conséquences de ce job : la queue workflow est bloquée, on n'historise plus aucune ressource statique jusqu'au reboot du worker et on va stopper de nouveau si on tombe sur une ressource qu'on a du mal à historiser (serveur HTTP qui met plus de 2 minutes à répondre, vu en production…).

Si on n'historise plus les ressources statiques, ensuite :

• on n'a plus les bonnes informations des ressources affichées dans l'API
• plus de validations
• plus de conversions
• plus de visualisations
• plus de notifications par rapport aux nouvelles données
• on risque de prévenir d'expiration de données alors que les données ont été mises à jour (on ne détecte pas le changement de ressource)

[AntoineAugusti]

Les workflows s'exécutent correctement

select state, count(1)
from oban_jobs
where queue = 'workflow'
group by 1

state	count
available	27
executing	2
completed	838
discarded	9

On retrouve bien des jobs avec des Oban.TimeoutError.

select distinct args->'first_job_args'->'resource_id'
from oban_jobs
where queue = 'workflow'
  and state = 'discarded'
  and errors::text ilike '%timeouterror%'
;
-- 81380
-- 81381
-- 81382
-- 81383

Ces 4 ressources sont bien indisponibles actuellement, il est donc cohérent d'avoir eu un timeout quand on a tenté de les historiser.

Exemple : https://transport.data.gouv.fr/resources/81380

[AntoineAugusti]

Oban a clarifié la documentation oban-bg/oban@c826da3