A failed fetch leaves the acquired batch to the reaper
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 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分
- マージ済み PR（30日）
- 27
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
似ている issue
-
Use mhctools predictor_required=False for saved-result rescoring対応中かも @iskandr が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
521xueweihan/HelloGitHub#4051 · コメント 1 件 ·
-
bug documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
awslabs/visual-asset-management-system#514 ·
メンテナーはふだん 1 日以内に返信
-
backend bug spec:REQ-053
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
nolte/kamerplanter#2547 ·
メンテナーはふだん 1 日以内に返信