Este equipo de especialistas despúes de varios días de investigación y recopilar de datos, hallamos la respuesta, nuestro deseo es que te sea de utilidad para tu proyecto.
Solución:
Devuelva el task_id (que se proporciona desde .delay()) y luego pregunte a la instancia de apio sobre el estado:
x = method.delay(1,2)
print x.task_id
Cuando pregunte, obtenga un nuevo AsyncResult usando este task_id:
from celery.result import AsyncResult
res = AsyncResult("your-task-id")
res.ready()
Creando un AsyncResult objeto de la identificación de la tarea es la forma recomendada en las preguntas frecuentes para obtener el estado de la tarea cuando lo único que tiene es la identificación de la tarea.
Sin embargo, a partir de Celery 3.x, existen advertencias importantes que podrían molestar a las personas si no les prestan atención. Realmente depende del escenario de caso de uso específico.
De forma predeterminada, Celery no registra un estado “en ejecución”.
Para que Celery registre que se está ejecutando una tarea, debe configurar task_track_started para True. Aquí hay una tarea simple que prueba esto:
@app.task(bind=True)
def test(self):
print self.AsyncResult(self.request.id).state
Cuando task_track_started es Falseque es el predeterminado, el estado mostrado es PENDING aunque la tarea haya comenzado. si configuras task_track_started para Trueentonces el estado será STARTED.
El estado PENDING significa “no sé”.
Un AsyncResult con el estado PENDING no quiere decir nada más que Apio no conoce el estado de la tarea. Esto podría deberse a varias razones.
Por una cosa, AsyncResult se puede construir con identificadores de tareas no válidos. Tales “tareas” se considerarán pendientes por Celery:
>>> task.AsyncResult("invalid").status
'PENDING'
Ok, entonces nadie se va a alimentar obviamente identificaciones no válidas para AsyncResult. Bastante justo, pero también tiene por efecto que AsyncResult también considerará una tarea que se ha ejecutado con éxito pero que Celery ha olvidado como siendo PENDING. Otra vez, en algunos escenarios de casos de uso esto puede ser un problema. Parte del problema depende de cómo se configura Celery para mantener los resultados de las tareas, ya que depende de la disponibilidad de las “lápidas” en el backend de resultados. (“Tombstones” es el término que se usa en la documentación de Celery para los fragmentos de datos que registran cómo terminó la tarea). AsyncResult no funcionará en absoluto si task_ignore_result es True. Un problema más irritante es que Celery vence las lápidas por defecto. Él result_expires la configuración predeterminada se establece en 24 horas. Entonces, si inicia una tarea y registra la identificación en el almacenamiento a largo plazo, y más 24 horas después, crea una AsyncResult con él, el estado será PENDING.
Todas las “tareas reales” comienzan en el PENDING Expresar. así que consiguiendo PENDING en una tarea podría significar que la tarea fue solicitada pero nunca progresó más allá de esto (por cualquier motivo). O podría significar que la tarea se ejecutó pero Celery olvidó su estado.
¡Ay! AsyncResult no funcionará para mí ¿Que más puedo hacer?
prefiero hacer un seguimiento de metas que hacer un seguimiento de la las tareas mismas. Mantengo cierta información de tareas, pero es realmente secundaria para realizar un seguimiento de los objetivos. Los objetivos se almacenan en almacenamiento independiente de Celery. Cuando una solicitud necesita realizar un cálculo que depende de que se haya logrado algún objetivo, verifica si el objetivo ya se ha logrado, si es así, entonces usa este objetivo almacenado en caché, de lo contrario, inicia la tarea que afectará el objetivo y envía a el cliente que hizo la solicitud HTTP una respuesta que indica que debe esperar un resultado.
Los nombres de variables y los hipervínculos anteriores son para Celery 4.x. En 3.x, las variables e hipervínculos correspondientes son: CELERY_TRACK_STARTED, CELERY_IGNORE_RESULT, CELERY_TASK_RESULT_EXPIRES.
Todos Task objeto tiene un .request propiedad que la contiene AsyncRequest objeto. En consecuencia, la siguiente línea da el estado de una Tarea task:
task.AsyncResult(task.request.id).state
Aquí puedes ver las reseñas y valoraciones de los lectores
Más adelante puedes encontrar las acotaciones de otros administradores, tú igualmente tienes el poder insertar el tuyo si te apetece.