The task hash stores a queue_name field that no reader uses
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
從 threadmill/backends/redis.py 中的 enqueue hash mapping 開始，接著檢查 acquire 和 mover 指令碼，以及 issue 中描述的 reaper 行為。判斷是否應移除未使用的 queue_name 欄位，或應由 reader 讀取它；完成的條件是 hash 不再寫入未被消費的欄位，同時保留現有的 queue-name 行為。
由索引模型根據 Issue 內容生成。
描述
Found while reviewing PR #69 with the SuperJoe crew. Filed as out-of-scope there.
RedisTaskBackend.enqueue() stores queue_name in the task hash. No reader uses it. The acquire and mover scripts read data and score. The reaper only makes sure that the hash exists. Every reader takes the queue from task.queue_name in the payload or from the key that holds the id. The backend writes this field on each enqueue, but no code reads it.
Remove the field, or make one reader use it. Then the payload does not need to carry the queue name as well.
Reference: threadmill/backends/redis.py, the enqueue hash mapping.
- 主要語言
- Python
- 星號
- 21
- 分支
- 2
- 平均合併
- 12 小時 39 分鐘
- 30 天內合併 PR
- 27
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
相似的 Issue
-
bug
難度 2/5 1-3 小時 新手友好度 79/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
mohitmishra786/readprism#322 ·
維護者通常 1 天內回覆
-
good first issue
難度 2/5 1-3 小時 新手友好度 76/100
-
難度 1/5 1 小時以內 新手友好度 75/100
維護者通常 1 天內回覆
-
API-key credentials accept a blank key: empty via the API, spaces-only via the builder's Add API key dialog可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 77/100
Significant-Gravitas/AutoGPT#15727 ·
維護者通常 1 天內回覆