feat(pipeline): 派发决策上移 plaita console——keeper 退化为探测器+收尸者，本地/远端多 worker 统一领单

オープン
  • 何か問題がありますか？
#16 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python, redis
領域
backend-api-design, distributed-systems

調査の方向性

Start by reading flows/pipeline_bridge.py, plaita/server/task_queue.py, plaita/server/execution_lease.py, and plaita/server/registry.py, then trace the existing pipeline dispatch path and the console _enqueue() entry point in plaita-console/backend/api/executions.py. The issue defines four phases and acceptance checks for local-mode compatibility, claim-mode delegation, duplicate prevention, and rollback; this is broad cross-system design work rather than a self-contained first change.

索引モデルが issue の本文から書いたものです。

説明

keeper-ignore

优先级 P1 · 依赖：无

基线 HEAD = 16fa769（git -C issue-keeper rev-parse --short origin/main）

Summary

把「派发决策」从 keeper 上移到 plaita console，keeper 退化为「探测器 + 收尸者」，本地/远端各起多个 worker 向 console 领单。当前结构性缺口（亲读证据）：

  • 两个 keeper 各自扫自己那份绑定表，互不知情：本机 ~/.issue-keeper/state.json 与远端 tcloud_gz 的 state 完全独立；本机 config.yaml 的 pipeline_max_in_flight / pipeline_priority_repos / author_daily_limit 均为 per-keeper 本地配置。实证：本机排队 62 条（recursive 待派 27 / plaita 待派 18）同时远端九仓仅剩 1 条待派——一边积压一边空转。
  • console 只存定义、不参与派发：flows/pipeline_bridge.py:7 注释原文「混合形态：定义与观测归 plaita-console，执行留本仓」；pipeline_bridge.py:11-15 的降级链只解析 flow 定义，不含任何派发逻辑。
  • plaita 侧分布式能力已齐备但未被派发层使用：plaita/server/task_queue.py（Redis Stream 消费组抢单、DEFAULT_CLAIM_MIN_IDLE_MS=60_000、DEFAULT_MAX_DELIVERIES=5、DLQ）、plaita/server/execution_lease.py（DEFAULT_LEASE_TTL_SECONDS=120 + fencing token，跨机防双跑）、plaita/server/registry.py（worker 注册/30s 心跳）。console 已有发单入口 plaita-console/backend/api/executions.py:148 _enqueue() → plaita/server/task_queue.enqueue_task()。

影响

  • 产能浪费：本机 3 并发跑满时 62 条排队，远端 2 并发闲置——全仓吞吐被单机封顶。
  • 运维耦合：改并发/优先级必须改每个 keeper 的本地 config 并重启 daemon（launchd kickstart）——无法全局调节。
  • 无法按容量避险：本机 2026-10-06 10:10 磁盘触底 0 字节（shell 写失败实证，见 ~/.issue-keeper/pipeline/controller/rounds.log 当日行）时，派发侧无从知晓并继续往本机压单。
  • 跨机同仓双跑风险靠"绑定表切分"人工维持：keeper-remote-worker-tcloud-gz 记录「同一仓只归一侧」，一旦两边绑定表漂移即双跑（#136 家族同工作区互杀）。

建议

分四阶段（每阶段可停可回退）：

  • P0 迁移：plaita console 从本机迁至 tcloud_gz（当前 console 实测在本机 pid 94089 监听 127.0.0.1:8123；远端 8123 为 docker-proxy 非 console，远端经 ssh -R 隧道以 PLAITA_CONSOLE_URL=http://127.0.0.1:18123 反连本机）。
  • P1 全局可见（只读）：console 汇总两台 state → 全局队列/worker 面板，不改编排。
  • P2 队列化派发：新建 issue-intake flow 承担派单；keeper 改为「扫 issue → 入队」与「run 终态 → 回评/关闭」；worker 改为「从 Stream 领单」。必须：新增 SCHEDULER_MODE=local|claim 开关与 delegated_repos（让 keeper 对已委托给新系统的仓只扫不派），否则新旧两套会争抢同一 issue。
  • P3 容量感知 + 收尸 flow 化：worker 上报负荷（磁盘/内存/在跑数），不足者自动摘除；issue-reaper flow 接管终态处理。

验收条件（逐条可断言）：

  1. SCHEDULER_MODE=local 时行为与当前完全一致（回归：既有 pipeline 全链跑通、台账格式不变）；
  2. SCHEDULER_MODE=claim 且 delegated_repos=[X] 时，keeper 对 X 仓不派发（日志断言零派发）、X 仓的单由 worker 领单执行，且同一 issue 不出现两次执行（execution_lease 持锁断言）；
  3. 并行验证期（金丝雀）：新系统只接指定仓，旧流程跑其余仓，两套台账可对照且互不污染（队列名隔离断言）；
  4. 切换仅需改配置（不改代码、不重启 worker 之外无其它动作）；回退=改回配置。

边界

  • 不做：不改 issue-pipeline flow 主体（60 节点复用，仅入口改为领单）；不做多租户收窄（README 已标该边界）。
  • 并行验证（jeffkit 2026-10-06 要求）：新系统跑通前不切流；验证期采用「影子模式（只算不发）→ 金丝雀（按仓）→ 全量」三步，禁止全量双跑同一 issue。
  • 与 plaita 配套单（console 侧 intake/heartbeat/reaper flow 与容量上报）互相引用。
主要言語
Python
スター
0
フォーク
0
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

jeffkit/issue-keeper のほかの issue

jeffkit/issue-keeper の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。