Jobs de transcodage
Editor, manager, admin
Lire l'état d'un job, comprendre les erreurs fréquentes et savoir quand relancer ou annuler un traitement.
Lecture par rôle
Editor
Lit les erreurs concrètes avant de relancer, surtout pour les jobs de proxy, de share dédié ou de watermark.
Manager
Surveille l'impact produit des échecs: shares bloqués, assets non publiables, retards de livraison.
Admin
Diagnostique les problèmes d'infra, de worker, de queue ou de stockage quand les erreurs se répètent.
FAQ
Quand relancer un job failed ?
Seulement après correction de la cause (source manquante, preset invalide, problème infra). Sinon il échouera à nouveau.
Pourquoi un job n'est plus relancé automatiquement ?
Après `max_retries`, il est considéré en échec permanent et ne doit plus être requeue pour éviter les boucles.
États de job
- Pending: job créé mais pas encore pris en charge.
- Processing: worker en cours de traitement.
- Completed: sortie générée avec succès.
- Failed: erreur définitive après retries ou échec permanent.
Diagnostic rapide
- Lire le preset, la source et le message d'erreur avant de relancer.
- Si un job de share dédié échoue, vérifier aussi le SharedStream correspondant.
- Un job qui atteint max_retries ne doit plus re-rentrer en boucle.
Playbook opérationnel
- Qualifier l'échec (source, preset, infra, stockage) avant toute action corrective.
- Ne relancer que les jobs dont la cause est corrigée pour éviter les files d'attente inutiles.
- Escalader côté infra quand plusieurs jobs similaires échouent sur une fenêtre courte.