La création d'un AsyncResult
objet à partir de l'ID de tâche est la méthode recommandée dans la FAQ pour obtenir l'état de la tâche lorsque la seule chose dont vous disposez est l'ID de la tâche.
Cependant, à partir de Celery 3.x, il y a des mises en garde importantes qui pourraient mordre les gens s'ils ne font pas attention à eux. Cela dépend vraiment du scénario d'utilisation spécifique.
Par défaut, Celery n'enregistre pas un état "en cours d'exécution".
Pour que Celery enregistre qu'une tâche est en cours d'exécution, vous devez définir task_track_started
sur True
. Voici une tâche simple qui teste ceci:
@app.task(bind=True)
def test(self):
print self.AsyncResult(self.request.id).state
Quand task_track_started
est False
, qui est la valeur par défaut, le show d'état est PENDING
même si la tâche a commencé. Si vous définissez task_track_started
sur True
, l'état sera STARTED
.
L'État PENDING
signifie «je ne sais pas».
Un AsyncResult
avec l'étatPENDING
ne veut rien dire de plus que le céleri ne connaît pas l'état de la tâche. Cela peut être dû à un certain nombre de raisons.
D'une part, AsyncResult
peut être construit avec des identifiants de tâches non valides. Ces «tâches» seront considérées comme en attente par Celery:
>>> task.AsyncResult("invalid").status
'PENDING'
Ok, donc personne ne va fournir des identifiants manifestement invalides AsyncResult
. Assez juste, mais cela a aussi pour effet de AsyncResult
considérer également une tâche qui s'est déroulée avec succès mais que Céleri a oublié comme étant PENDING
. Encore une fois, dans certains scénarios de cas d'utilisation, cela peut être un problème. Une partie du problème dépend de la façon dont Celery est configuré pour conserver les résultats des tâches, car cela dépend de la disponibilité des «tombstones» dans le backend des résultats. ("Tombstones" est le terme utilisé dans la documentation Celery pour les blocs de données qui enregistrent la fin de la tâche.) L'utilisation AsyncResult
ne fonctionnera pas du tout si task_ignore_result
c'est le cas True
. Un problème plus épineux est que Celery expire les pierres tombales par défaut. leresult_expires
le réglage par défaut est défini sur 24 heures. Donc, si vous lancez une tâche et enregistrez l'identifiant dans le stockage à long terme, et plus encore 24 heures plus tard, vous créez un AsyncResult
avec elle, le statut sera PENDING
.
Toutes les «vraies tâches» commencent dans l' PENDING
état. Ainsi, entreprendre PENDING
une tâche pourrait signifier que la tâche a été demandée mais n'a jamais progressé plus loin que cela (pour une raison quelconque). Ou cela pourrait signifier que la tâche s'est exécutée mais que Celery a oublié son état.
Aie! AsyncResult
ne fonctionnera pas pour moi. Que puis-je faire d'autre?
Je préfère garder une trace des objectifs que de suivre les tâches elles-mêmes . Je garde certaines informations sur les tâches, mais elles sont vraiment secondaires au suivi des objectifs. Les buts sont stockés dans un stockage indépendant du céleri. Lorsqu'une demande doit effectuer un calcul dépend de l'atteinte d'un objectif, elle vérifie si l'objectif a déjà été atteint, si oui, elle utilise cet objectif mis en cache, sinon elle démarre la tâche qui affectera l'objectif, et envoie à le client qui a fait la demande HTTP une réponse qui indique qu'il doit attendre un résultat.
Les noms de variables et les hyperliens ci-dessus concernent Celery 4.x. Dans 3.x les variables et les liens hypertextes correspondants sont: CELERY_TRACK_STARTED
, CELERY_IGNORE_RESULT
, CELERY_TASK_RESULT_EXPIRES
.
x
?