时间戳

首页 > 解决方案 > 芹菜：损坏的状态有效载荷。可能的原因？装饰__call__()方法的原因？

python - 芹菜：损坏的状态有效载荷。可能的原因？装饰__call__()方法的原因？

问题描述

我正在尝试诊断这一点，但想把问题抛在脑后，以防有人看到这样的事情。

基本上我看到的是 AsyncResult(task_id)，返回一个状态为 None 的结果。

令人毛骨悚然。

我正在使用 rpc: 后端。

所以我深入研究了 Celery 代码和 RabbitMQ 队列，从两个角度我都可以看到状态消息如下所示：

dict: {'task_id': 'STARTED', 'status': None, 'result': {'pid': 24113}, 'traceback': None, 'children': []}

明显腐败。STARTED 应该处于状态。

我什至对造成这种情况的原因有一些线索，我只需要证明它并找到证据，以及如何解决它。至少可以说很费力，所以我很乐意a）提供任何经验来加速它，b）如果我确实解决了它，为了后代把它记录下来（以防其他人遇到这个） .

这可能（也许）与我装饰任务有关。调用（）方法。但我一直在想怎么做。

一个洞察力的宝石将是 Celery 中的状态消息在哪里发送到支持的 RPC 队列？它似乎编译错误。到目前为止，我已经跟踪到将任务启动事件发送到 celerev 交换（对于我想象的事件），并且可能是这个事件触发了要发送的状态更新。

我会继续钻研。但是当我睡觉时，也许其他人有线索？

标签： pythonceleryiasyncresult

解决方案

呵呵，发现问题了。并且不确定这何时进入代码库！

我花了很多时间跟踪代码来发现这一点，最终几乎令人尴尬，而且完全是盲目的人为错误。中断的代码是：

self.update_state(state, meta=meta)

有效的是：

self.update_state(state=state, meta=meta)

这仅仅是因为 Task.update_state() 有这个签名：

def update_state(self, task_id=None, state=None, meta=None, **kwargs):

即我们，task_id 我们默认。在某些时候，由于某种原因，工作代码被改变了。嗯，关于如何以及何时不清楚的故事唉（提交之间相当重要的重构的一部分）。

令人沮丧的是，回想起来这是我应该看的第一个地方。我认为我失败的原因是第一次 Celery 状态更新（标准 Celery 状态更新（STARTED）已损坏，并且不是由我修复的上述行生成的。对我来说很神秘。

推荐阅读