Celery - 超过最大重试次数后重新提交失败的任务链

Question

我正在用django芹菜。我必须为用户提供检查失败任务的选项，必要时对失败的任务数据进行修改并再次提交。 我见过这个帖子 - Celery Storing unrecoverable task failures for later resubmission。 所以我知道芹菜不存储任务的原始args和kwargs，我们需要照顾它。这样做我很好。 但是如果我有一个主要任务“MainTask1”提交链“SubTask1 | SubTask2 | SubTask3”并且如果SubTask2失败，那么我看到SubTask3不会被执行直到SubTask2成功。但是如果SubTask2在最大重试后失败，那么SubTask3永远不会被提交。

我的问题是 -

1. 当SubTask2失败时，我可以坚持它的args和kwargs。但是，如何获取链中剩余任务的信息？

2. 究竟是什么存储在celery_taskmeta表的'result'和'meta'列中？

3. 表格celery_tasksetmeta何时填充？

谢谢，

Answer 1

1. 您可以使用结果（例如AsyncResult(id).ready，请参阅http://docs.celeryproject.org/en/latest/reference/celery.result.html），但使用amqp后端无法可靠地完成此操作，因为只有一个进程可以检索结果。

2. 后端APi中使用的名称不一致且过时。 这是因为术语随着时间的推移而演变了很多，后端也有 自芹菜0.1起，它几乎是向后兼容的。 首先，任务仅在成功或失败时存储数据。这使用了字段status和result。最终我意识到很容易将其扩展到支持随着任务进展而更新的任意状态，而这只是在已经存在的情况下实现。

   结果字段包含任务成功时任务的返回值，或者任务失败时引发的异常。自定义状态可以在此字段中存储任意数据，因此在较新的术语中，任务状态可以附加信息，这就是存储的位置。

   稍后添加了元字段，因为我厌倦了一直添加新字段（并强制用户迁移模式），它用于不需要编制索引的新字段，目前仅用于保存children属性，该属性是由任务

   启动的子任务ID列表

   希望有朝一日可以清理它。大多数其他＆＃39;成长的痛苦＆＃39;已经在很久以前被重构过，但结果后端仍然存在。

3. GroupResult.save（以前的TaskSetResult）用于存储组结果 为了以后的检索，您只需保留组ID即可获取组中的任务ID列表。此功能仅供Redis结果后端用于此时实现和弦，这将在未来发生变化，因为它对于具有许多任务的组来说效率不高。保存选项是由用户请求实现的，但我认为包含它是一个不好的选择，并且用户做得更好（比如你提到的存储任务参数/ kwargs）