Les WebJobs sont des éléments classiques d'une architecture cloud qui permettent des traitements réguliers en tâche de fond dans le même contexte que votre API et sans coût supplémentaire. Dans cet article, nous verrons comment empêcher un WebJob continuous de s'éteindre tout seul en plein traitement.

2 types de WebJob 

Il existe deux types de WebJob : Continuous ou Triggered. Un job triggered est déclenché à la demande (appel HTTP, récurrence timée, etc.) puis tué après, et un job continuous est démarré immédiatement pour ne pas s'arrêter. S'il s'arrête pour une raison x ou y, il sera redémarré automatiquement.

Un job continous a cependant des déclencheurs : son process tournera tout le temps mais des traitements spécifiques peuvent être faits à la demande. Ainsi, pour importer régulièrement un fichier, on peut avoir un webjob Continuous avec un TimeTrigger.

Non-extinction automatique d'un WebJob Continuous

Il va sans dire que le cycle de vie d'un Webjob est lié à celui de l'AppService qui l'héberge. La première chose à faire si l'on souhaite que le WebJob ne soit pas stoppé est donc de configurer l'AppService en AlwaysOn (et comme le dit la documentation "It's required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.") :

Une fois cela fait, on s'estime tranquille et on retourne se confiner dans notre salon... mais cela n'est pas suffisant. Il existe en effet un autre paramètre qui coupe automatiquement votre WebJob si le runtime décide qu'il ne fait rien. Ce paramètre n'est pas dans la documentation Microsoft mais dans celle de Kudu (l'outil de diagnostic de vos AppServices) car c'est lui qui surveille votre WebJob (code source). La valeur par défaut est de 120 secondes, ce qui est assez court. Pour changer sa valeur, il suffit de renseigner le paramètre WEBJOBS_IDLE_TIMEOUT à une valeur suffisamment grande pour votre contexte. 

Je ne sais pas précisément ce que le runtime considère comme inactif mais je le trouve d'expérience assez ouverte sur la question... On peut trouver ici et là sur l'internet mondial des personnes indiquant qu'il suffit d'écrire des logs dans la console pour empêcher d'être considéré comme actif. Seulement la quantité de logs pouvant être écrite dans ce qu'il surveille est limitée et vous avez rapidement ce type de message et plus aucun log écrit et donc un webjob rapidement considéré comme inactif : 

[04/10/2020 02:28:52 > b40e06: WARN] Reached maximum allowed output lines for this run,
to see all of the job's logs you can enable website application diagnostics

 Autre information, si vous rencontrez ce problème mais que vous pouvez encore écrire des logs, vous aurez bien ce beau message affiché dans la console de suivi du WebJob. Cela devient tout de suite plus simple à corriger :

XXXXX was aborted due to no output nor CPU activity for 120 seconds.
You can increase the SCM_COMMAND_IDLE_TIMEOUT app setting (or WEBJOBS_IDLE_TIMEOUT if this is a WebJob) if needed.

Happy coding :)

PS : pour aller plus loin avec les Webjobs, cet article fait partie d'une mini-série dont vous trouverez le premier article ici.