fix(poller): cap pollComments fetches per repo per invocation

[liplus-lin-lay]

概要

pollComments の per-repo fetch 数に上限を追加し、Cloudflare Worker の 1 起動あたり 1000 subrequest 上限を超過する問題を修正する。

背景

2026-04-26 の cron 実行で、Liplus-Project/dipper_ai の pollComments が Too many subrequests by single Worker invocation で落ちている事象が観測された (issue #134)。他の 4 repo (github-rag-mcp / github-webhook-mcp / liplus-language / liplus-desktop) では同事象は出ていない。

既存の cap は 2 段:

• MAX_COMMENT_BACKFILL_PARENTS = 20 (per-repo の parent 数上限)
• MAX_COMMENTS_EMBEDDED_PER_REPO = 30 (per-repo の embedding 数上限)

ただし各 parent は 3 endpoint (issue comments / PR reviews / PR review comments) に fan-out するため、最悪ケースで 1 repo あたり 60 fetch を発行する。dipper_ai のように comment 量の多い repo では、他の poller (diff / wiki / issue) と合算して subrequest budget を使い切る。

修正方針

#130 / PR #131 (wiki 側) と同じパターンを採用する。embed cap とは独立した「fetch (probe) cap」を導入する。

• 新定数 MAX_COMMENT_FETCHES_PER_REPO_PER_RUN = 30 を追加
• per-parent loop 内で fetch 発行のたびに counter を increment
• 上限到達で loop を打ち切り、warn log を出力
• summary log に fetches_issued=N/MAX を追加して観測しやすくする

cap 値 30 は wiki 側の MAX_WIKI_PAGES_PROBED_PER_REPO_PER_RUN = 20 と整合的なオーダで、MAX_COMMENTS_EMBEDDED_PER_REPO と同じ値に揃えた。最大 30 fetch なら 5 repo 並走でも 150 subrequest で、他 poller と合算しても 1000 budget に収まる。

既存挙動への影響

• 4 つの稼働中 repo は parent 数 × 3 endpoint が常時 30 fetch 未満で動いているため、挙動退行はない。
• dipper_ai のように cap に到達する repo では、未処理 parent は次の cron で自然に拾われる (cron は hourly)。

ファイル

• src/poller.ts (+40, -0)

テスト

• npx tsc --noEmit pass

補足

execution mode = auto のため、本 PR は AI 自律 self-review を経て merge する。

Closes #134

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	github-rag-mcp	8fb17f8	Apr 27 2026, 09:48 AM

[liplus-lin-lay]

AI self-review (auto mode)

issue #134 の acceptance criteria に対する自己レビュー。

1. 根本原因 (subrequest fan-out) を解消しているか

YES。pollComments の per-parent fan-out は最大 3 endpoint で、MAX_COMMENT_BACKFILL_PARENTS = 20 下では最悪 60 fetch / repo / run。これを 30 fetch に bound し、subrequest budget 1000 内に収まるようにした。embed cap (MAX_COMMENTS_EMBEDDED_PER_REPO = 30) は embed が走った後に判定されるため fetch 抑制には効かない — 別軸 cap が正しい修正。

2. 4 つの稼働中 repo で挙動退行はないか

NO regression。観測 log では 4 repo の comment fetch fan-out は parent 20 弱 × 部分的な PR (review/review_comments がある parent のみ) なので、実 fetch 数は 30 未満で運用されている。新 cap 30 はその上に置く safety net。

3. cap 値 30 の妥当性

• wiki 側 MAX_WIKI_PAGES_PROBED_PER_REPO_PER_RUN = 20 と同オーダ
• MAX_COMMENTS_EMBEDDED_PER_REPO = 30 と揃えて mental model を単純化
• 5 repo 並走で 5 × 30 = 150 subrequest、他 poller (diff / wiki / issue) と合算しても 1000 budget の数十%に収まる
• dipper_ai は次 cron で残り parent を拾えるので情報損失なし (cron hourly)

4. 不要変更の混入

なし。src/poller.ts の 40 行追加のみ (cap 定数 + counter + budget check + warn log + summary log の fetches_issued 表示)。git diff origin/main..HEAD --stat で確認済。

5. PR #131 (wiki 側) パターンとの整合性

mirror できている:

• 別軸 cap 定数 (probe/fetch) を embed cap と独立に追加
• counter を per-iteration で increment
• cap 到達で loop break + console.warn で観測
• jsdoc に issue #(130/134) 番号と「次 cron で拾う」設計意図を明記

Verdict

APPROVE。issue #134 の root cause を address し、proven-good pattern (#131) を mirror。挙動退行リスクなし。merge 可。