#2452·rq

result_ttl 在尚未运行的依赖项仍然需要该完成作业时删除该作业

作者: jimzer创建于 2026年8月7日更新于 2026年9月8日

你好,感谢 RQ,我们非常依赖它。 我们在作业依赖方面遇到了一些问题,感觉像是一个 bug,所以想先和你商量一下。 当一个作业完成时,其 `result_ttl` 会立即开始计数,即使它还有尚未运行的依赖项。 如果其中一个依赖项只在稍后运行,那么在依赖项运行时,该依赖项已经被驱逐,并且依赖项无法查找到它。 最小的重现(需要本地 Redis): https://gist.GitHub.com/jimzer/af1146df7220c9b043d98900c4928ca0 它先排队 A,然后 B `depends_on` A,只运行 A,等待 A 的短 `result_ttl` 过期,然后运行 B: 运行 A 后: A = JobStatus.FINISHED | B = JobStatus.QUEUED A 仍在 Redis 中? False (B 仍然依赖它且尚未运行) 运行 B 后: B = JobStatus.FAILED | rq.exceptions.NoSuchJobError: No such job: rq:job:... 设置 `RESULT_TTL=3600` 可以保留 A 并使 B 完成得很好,因此 `result_ttl` 是唯一的变量。 从我们的角度来看,一个仍然是未完成作业的依赖项的 `result_ttl` 不应该从作业完成时开始计数,而是从其依赖项完成时开始计数。 基本上,一个尚有依赖项的已完成结果不应该被垃圾回收。 其余部分保持了正常的 "在 N 秒后清理已完成结果" 行为。 还有几个细节需要确定(例如,如果一个依赖项失败,应该保留什么),我很乐意解决这些问题。 这与你的看法是否一致,或者有没有理由它现在是这样运行的? 如果你愿意,我们很乐意编写一个 PR(如果你不想更改当前默认值,可以选择性地接受)。 谢谢!