fix: 移植中に判明した既存バグをまとめて修正（IssuesEvent加点/last_sanpaiクラッシュ/スケジュールGo関数デプロイ）#129
Merged
Conversation
GitHub Events APIのIssuesEvent payloadはオブジェクトで開閉種別はpayload.action (opened/closed/...)に入る(公式ドキュメントAPI 2022-11-28および実データで確認)。 移植前は payload そのものを文字列 opened/closed と比較しており決して一致せず、 Issueのオープン(intelligence+3)/クローズ(defence+5)が一度も加点されていなかった。 Go版(internal/performance)とNode版(performance.js)の両方で payload.action を 参照するよう修正。Issue活動のあるユーザーは intelligence/defence/total(戦闘力・ ランキング)が本来値に増加する。キャッシュ済み status は次回の sanpai または statusCacheBackfill で再計算されるまで旧値のまま(データ破壊なし)。 両実装のテストを修正後の正しい挙動に更新。docs/backend.md と performance/README に 経緯と影響を記載。 Co-authored-by: kojira <kojira@users.noreply.github.com>
status キャッシュはあるが last_sanpai(トップレベル)が無いユーザー(一度も参拝せず プロフィールを2回以上表示した場合など)に対して、Node版は undefined.toDate() で 例外になっていた。この場合は status 未保存時のフル計算パスと同じく 「参拝していないようです」を返すよう Go版(formatLastSanpai)・Node版の両方を修正。 formatLastSanpai のユニットテストを追加。docs/backend.md を修正内容に更新。 Co-authored-by: kojira <kojira@users.noreply.github.com>
Cloud Functions(Gen2)の --trigger-topic はGen1と異なりPub/Subトピックを 自動作成しない。存在しないトピックを指定すると `Validation failed for trigger ...: Resource not found` で即失敗するため、 rankingUpdateGo等のデプロイが失敗していた(env/dev CI run 28520938294)。 デプロイ前に4トピック(ranking-update-go/ranking-cache-go/ status-cache-backfill-go/scheduled-ogp-delete-go)を冪等に作成するステップを追加。 誤った前提を書いていたコメントも訂正。 Co-authored-by: kojira <kojira@users.noreply.github.com>
cursor
Bot
changed the title
IssuesEvent加点バグ修正により、修正前に保存されたstatusキャッシュは誤った 戦闘力・ランキングのまま残る。キャッシュ全削除などの破壊的操作なしにこれを 正しい値へ収束させるため、解析ロジックにバージョン印を導入する(案A)。 - performance: StatusLogicVersion(Go)/STATUS_LOGIC_VERSION(Node)=1 を追加。 計算式を変えたら必ずインクリメントする。 - status書き込み経路(status/sanpai/statusCacheBackfill、NodeのuserOGP)で トップレベル status_version に現行バージョンを刻む(statusオブジェクト自体には 含めずAPIレスポンス形状は不変)。 - キャッシュ再利用判定を共通ヘルパ(Go: statusCacheIsCurrent / Node: status_cache_is_current)に集約し、status有 かつ status_version>=現行 のときのみ再利用。それ以外はフル再計算し現行版を書き戻す。 - sanpaiの増分計算は基準が現行バージョンのときだけ行う。旧バージョンを基準に 増分すると過去分の誤りを現行版として固定化するため、その場合は全件再計算。 - statusCacheBackfillは未計算に加え旧バージョンのstatusも再計算対象にする。 - テスト追加: statusCacheIsCurrent単体テスト、旧バージョンstatusの再計算結合テスト。 既存のalready-cachedテストは現行バージョン印付きに更新。 - docs/backend.md・performance READMEに自己修復キャッシュの設計を記載。 Co-authored-by: kojira <kojira@users.noreply.github.com>
cursor Bot
pushed a commit
that referenced
this pull request
Jul 1, 2026
PR #129 の4修正を dev へ反映: - IssuesEvent を payload.action で加点(常時未加点バグ修正) - status の last_sanpai 未設定時クラッシュ修正 - スケジュールGo関数のPub/Subトピック事前作成(dev-deployデプロイ失敗の修正) - status_version による解析キャッシュのバージョン管理と自己修復 Co-authored-by: kojira <kojira@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
概要
Go移植中に判明した既存バグを、再現せずにまとめて修正します。これまでの「Node版のバグをそのまま踏襲する」方針を是正しました。スケジュール関数は起動・実行時間の課金削減のためGoのまま進めます（本PRでそのデプロイ失敗も修正）。
修正1:
IssuesEventの加点バグ（performanceGo/Node両方）IssuesEvent.payloadはオブジェクトで、開閉種別はpayload.action（opened/closed/...）に入る。payload.actionで判定するよう Go/Node × 全件計算/増分計算の4箇所すべてを修正。api.github.com）で確認。IssuesEventの構造は昔からオブジェクトで、これはスペック変更ではなく当初からのバグ。修正2:
statusのlast_sanpai未設定時クラッシュ（Go/Node両方）statusキャッシュはあるがlast_sanpaiが無いユーザーに対し、Node版はundefined.toDate()で例外になっていた。formatLastSanpaiのユニットテスト追加。修正3: スケジュールGo関数のデプロイ失敗（CI）
--trigger-topicはPub/Subトピックを自動作成せずResource not foundで失敗していた（env/dev CI run 28520938294）。修正4: 解析キャッシュのバージョン管理と自己修復（案A・レビュー指摘H-1の対応）
修正1で計算式が変わるため、修正前にキャッシュ済みの
statusは誤った戦闘力・ランキングのまま残る。キャッシュ全削除などの破壊的操作なしに正しい値へ収束させるため、ロジックにバージョン印を導入した。performanceにStatusLogicVersion(Go)/STATUS_LOGIC_VERSION(Node)=1を追加。計算式を変えたら必ずインクリメントする運用に。status書き込み経路（status/sanpai/statusCacheBackfill、NodeのuserOGP）で、ユーザードキュメントのトップレベルstatus_versionに現行バージョンを刻む（statusオブジェクト自体には含めずAPIレスポンス形状は不変）。statusCacheIsCurrent/ Node:status_cache_is_current）に集約。status有 かつstatus_version >= 現行のときのみ再利用し、それ以外（未保存 or 旧バージョン=フィールド無で0/undefined扱い）はフル再計算して現行版を書き戻す。sanpaiの増分計算は基準が現行バージョンのときだけ実行。旧バージョンを基準に増分すると過去分の誤りを「現行版」として固定化するため、その場合は全件再計算して基準ごと作り直す。statusCacheBackfill（直近半年アクティブを1実行10件ずつ）で順次再計算され、非破壊で自己修復する。テスト（すべてローカル実行済み）
gofmtクリーン /go vet ./...OK /go test ./...全パスstatusCacheIsCurrent単体テスト、旧バージョンstatusが再計算され現行版が刻まれる結合テスト（TestStatusCacheBackfill_RecomputesOldVersionStatus）actionlintでdev-deploy.yml検証OK（workflow変更は本セッション無し）第三者レビュー結果
3コミットの修正内容は正しく、Go/Node等価性・全件==増分の不変条件・テスト妥当性すべて合格（片側修正の漏れなし）と確認済み。レビューで指摘された唯一のHigh項目（H-1: キャッシュ再計算経路が無い）は修正4（案A）で対応済み。