Une tâche timeoute depuis qu’un runner séparé exécute le code. La variable doit aller sur le bon conteneur, et l’exécution manuelle diffère du worker.
Une tâche de fond timeoute systématiquement. Elle marchait avant. Un changement d’architecture a déplacé l’exécution, et la config est restée au mauvais endroit.
L’exécution est passée à un runner séparé
Avant, l’application exécutait elle-même ses tâches dans son propre processus. Désormais le code part vers un runner dédié : un worker distinct, dans son propre conteneur, qui consomme une file et exécute le travail.
Le timeout vient de là. Le worker n’a pas la même configuration que l’application web. La variable qui pointe vers la ressource lente, ou qui fixe la limite de temps, est posée sur le conteneur web mais absente du conteneur worker.
Poser la variable sur le bon conteneur
La variable doit aller sur le conteneur qui exécute réellement la tâche, le worker, pas sur celui qui la met en file. C’est l’erreur fréquente après ce type de bascule : la config suit l’ancien modèle d’exécution.
Pour le confirmer, on compare exécution manuelle et exécution par le worker. Lancer la tâche à la main depuis le conteneur web peut réussir, parce qu’elle s’exécute là où la variable existe. La même tâche via le worker échoue. L’écart désigne le conteneur à corriger.
Le principe : la config suit l’exécution. Quand l’exécution déménage vers un runner séparé, ses variables doivent déménager avec.