fix(poller): lower pollComments cap from 30 to 10 to fit Worker subrequest budget

[liplus-lin-lay]

概要

src/poller.ts の MAX_COMMENT_FETCHES_PER_REPO_PER_RUN を 30 から 10 に引き下げる。PR #136 で 30 を導入した直後の本番観測で、cap=30 でも Too many subrequests が解消していないことを確認したため。

観測根拠

2026-04-28T15:15 UTC の :15 pollComments cron (再デプロイから約 33 分後):

• 5 repos すべてで fetches_issued=30/30, fetch_failures=30, Too many subrequests
• 警告 pollComments: fetch budget reached は発火しているが、cap=30 に到達する前に Worker の 1000-subrequest-per-invocation budget を使い切っている
• 1 fetch あたりに Vectorize embed + D1 FTS upsert + Workers AI + Store DO 呼び出しなどの overhead が乗るため、5 repos × 30 fetches × ~3-5 subrequests で 1000 を超過

数値根拠

• cap=10: worst-case 5 × 10 = 50 fetches × ~5 subrequests ≈ 250 + parent overhead → 1000 budget 内に収まる
• 残りの parent は次回 cron で順次拾う設計 (元のコメントのまま)

注意

• これは PR fix(poller): cap pollComments fetches per repo per invocation #136 の incremental 修正。issue bug(poller): pollComments exhausts Worker subrequest budget on dipper_ai #134 は Refs 留めで OPEN を維持し、merge 後 :15 cron 1-2 周で fetch_failures=0 を確認してから close する。
• 自律 loop fire v0.1.0 roadmap: GitHub issue/PR structured search MCP server #1 (axis-1 follow-up) として実行。Master 起床までに self-review + CI green + self-merge を予定。

Refs #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	b26718b	Apr 28 2026, 03:30 PM

[liplus-lin-lay]

Self-review (auto mode)

観測根拠の妥当性

2026-04-28T15:15 UTC の :15 cron で 5 repos 全てが fetches_issued=30/30, fetch_failures=30, Too many subrequests を記録した観測は、cap=30 が 1000-subrequest budget に対して過大であることの直接証拠。pollComments: fetch budget reached warn 発火と Too many subrequests 同時発生は、cap が機能していても fetch 時点で既に budget が枯渇している状態を示す。

cap=10 の overhead 計算

• worst-case: 5 repos × 10 fetches = 50 fetches
• 1 fetch あたり ~3-5 subrequests (Vectorize embed + D1 FTS upsert + Workers AI + Store DO)
• 50 × 5 = 250 subrequests + per-parent overhead + diff/wiki/issue poller の余地
• 1000 budget に対して headroom 750+ あり、十分な余裕

Regression risk

• 4 working repos は元々 issue 数が少なく cap に到達していなかった (fetches_issued < 30)。cap=10 でも実数値が 10 未満であれば挙動不変。
• dipper_ai のみ高 issue 数で cap が制約だったが、cap=30 でも budget exhaust していたのだから、cap=10 で fetch 数が減ることは前進方向の変更。
• 残り parent は次 cron で拾う設計が元から入っているので、見落としは発生しない。

検証経路

1. merge → CD → 再デプロイ (Cloudflare Workers)
2. 次の :15 cron 1-2 周で fetch_failures=0 または大幅減を確認
3. 確認後、issue #134 を close

判断

LGTM. Self-approve 相当 (auto mode は formal approve なし、self-review コメントで gate 通過)。