参拝時のGitHubイベント取得を100件→300件にする(取りこぼしを止める)

[kojira]

現状

sanpai.go:139 で Events API を 1ページだけ取得している。

"%s/users/%s/events/public?per_page=100"

Link ヘッダを辿っておらず、ページングのコードが無い。100件はうちの実装側の制限で、
GitHub の制約ではない。

GitHub 側の本当の上限:

• Events API は最大300件(100件 × 3ページ)
• 90日より古いイベントは返らない
• 公開イベントのみ

何が起きているか

前回の参拝から公開イベントが100件を超えると、超えた分は永久に取りこぼす。
次に参拝しても、そのイベントはもう1ページ目に無いため。活発に動いた人ほど損をする。

取りこぼすのは「ぽいんと」(len(splited)/5)と「せんとうりょく」(能力値)の両方。

やること

Link ヘッダを辿って最大3ページ(300件)まで取得する。

影響範囲(調査済み)

呼び出し元

fetchGitHubFeed の呼び出しは sanpai.go:326 の1箇所のみ(他は sanpai_test.go)。
github_stats.go は別のAPIを叩いており無関係。

⚠️ sanpaiGo のタイムアウトが30秒

prod-deploy.yml:222 で --timeout=30s --memory=256Mi。ここが一番の懸念。

• GitHub API 呼び出しが 1回 → 最大3回
• Firestore の batch.Set が最大100件 → 最大300件(バッチ上限500なので収まるが、コミット時間は伸びる)
• 初回参拝(status未保存)は全件再計算パスに入るため、さらに重い

対策案:

• ページの最古イベントが since 以前ならそこで打ち切る。通常の参拝は1リクエストのままで済む
• 3ページを並列で取る
• それでも足りなければ --timeout=60s へ引き上げ

ポイントの増え方が変わる

addExp += len(splited) / 5

1回の参拝で最大 +20 → 最大 +60 になる(バーストした人ほど増える)。
取りこぼしを止めるのが目的なので意図どおりだが、ぽいんとランキングの動きが変わる。
バランス上の判断が要るなら分母を見直す余地あり。

過去分は復元できない

90日を過ぎたイベントは GitHub からもう返らないため、既存ユーザーの過去の取りこぼしは
取り戻せない。今後の取りこぼしが止まるだけ。

二重計上は起きない

github_activities は Doc(it.Event.ID) で保存しており、同じイベントIDは上書きされる。
splited は created_at > last_sanpai で絞っているため、既に集計済みの分は入らない。

せんとうりょく・期間ランキング

1回の参拝で伸びる量が増えるので battle_logs の1件あたりの値も大きくなる。
仕組み上の問題は無い(イベントの合計であることは変わらない)。

受け入れ条件

• Link ヘッダを辿って最大3ページ取得する
• 取得済みの範囲に達したら早期に打ち切る(通常の参拝でAPI呼び出しを増やさない)
• sanpaiGo が30秒に収まることを確認する(収まらなければタイムアウトを上げる)
• 300件取得時に Firestore バッチが上限(500)を超えないことを確認する
• モックで複数ページのテストを追加する