A failed fetch leaves the acquired batch to the reaper
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
调研方向
Start with acquire.lua and trace how leased tasks are handled when TaskResult deserialization fails. Then inspect maintain_worker_pool and the reaper's lease-expiry behavior. Done means fetch failures no longer silently lose leased tasks and the intended worker-drain behavior remains intact.
由索引模型根据 Issue 内容生成。
描述
Deferred from the task-prefetching review (crew run): the error path is now loud and the worker exits non-zero, but returning the tasks is the larger design piece.
What
acquire.lua leases every task of a batch (ZADD into the running set with the lease deadline, task data rewritten RUNNING) before the reply is deserialized. If the fetcher then raises — a poison payload that fails TaskResult reconstruction, a renamed or removed task function, a broker error mid-reply — the whole leased batch is discarded:
- the batch is never buffered, never executed, and never acknowledged
- the reaper moves it to the failed history after
lease_ttl(default 1 hour) and never back to READY, so the tasks are lost unless an operator requeues them - with
--exit-empty, dead workers arecontinued bymaintain_worker_pool, so a broker outage across the fetchers can end the whole drain run as if the queue were empty
Reproduced dynamically: one worker, 2 threads, prefetch_count=4, a backend leasing 4 tasks and then failing to deserialize one — 4 tasks leased, 0 acknowledged, worker exited 0 before the loudness fix.
Options
- add a backend
release()/unacquire call that returns a leased task to READY (the inverse of the lease the acquire script takes), and call it for the buffered-and-unstarted remainder on a fetch failure - or lease only after the reply is fully deserialized (changes the atomicity story: the script must not move tasks to the running set until the client has them)
- or make the reaper hand back rather than fail on the first expiry, if a retry-once policy is acceptable
Related: the same "leased but never executed" window exists for a hard kill, which is accepted behaviour (the reaper covers it); this issue is about the error path where the run continues.
- 主要语言
- Python
- 星标
- 21
- 派生
- 2
- 平均合并
- 12 小时 39 分钟
- 30 天内合并 PR
- 27
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
相似的 Issue
-
难度 1/5 1-3 小时 新手友好度 66/100
AlexsLemonade/scpca-docs#518 ·
-
bug
难度 1/5 1 小时以内 新手友好度 95/100
rocketride-org/rocketride-server#2705 · 1 条评论 ·
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 85/100
Metabuilder-Labs/tokenjam#786 ·
维护者通常 1 天内回复
-
prototype(verifier_token): map disallowed warning to contraindicated before composite precedence check可能已有人在做 @drk-ram 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
agentrust-io/trace-spec#582 ·
维护者通常 1 天内回复
-
area:cli priority:low refactor size:small
难度 1/5 1 小时以内 新手友好度 88/100
RonaldHensbergen/composable-data-stack#906 ·
维护者通常 1 天内回复