Skip to content

⚡ Optimize GitHub Heatmap Fetching #361

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
is0692vs wants to merge 1 commit into
base: main
Choose a base branch
from
Open

⚡ Optimize GitHub Heatmap Fetching #361

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/lib/githubYearInReview.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -316,7 +316,7 @@ export async function fetchCommitActivityHeatmap(username: string, year: number,
url.searchParams.set("until", to.toISOString());
url.searchParams.set("per_page", "100");

const res = await fetch(url.toString(), { headers: headers(token), cache: "no-store" });
const res = await fetch(url.toString(), { headers: headers(token), cache: "force-cache" });

@gemini-code-assist gemini-code-assist Bot Jun 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Using force-cache unconditionally will cache the commit activity heatmap indefinitely. While this is correct and highly efficient for past years (which are immutable), it introduces a correctness bug for the current year, as any new commits made by the user will not be reflected in the heatmap.

We should conditionally apply force-cache only if the requested year is in the past, and fallback to no-store for the current year.

    const isPastYear = year < new Date().getUTCFullYear();
    const res = await fetch(url.toString(), {
        headers: headers(token),
        cache: isPastYear ? "force-cache" : "no-store"
    });

@greptile-apps greptile-apps Bot Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 現在年のデータが永久に陳腐化する問題

force-cache はリバリデーション期間を指定しないと Next.js のデータキャッシュに永続的に保存されます。year が現在の年の場合（例：2026年中に呼び出されると）、年の途中で新しいコミットが追加されても最初に取得したレスポンスが永遠にキャッシュされ続けます。PR 説明では「過去の不変データ」と述べていますが、この関数は過去年だけでなく現在進行中の年にも呼ばれます。過去年のみに force-cache を適用するか、{ next: { revalidate: 3600 } } などの TTL を設定する形を検討してください。

Prompt To Fix With AI 
This is a comment left during a code review.
Path: src/lib/githubYearInReview.ts
Line: 319

Comment:
**現在年のデータが永久に陳腐化する問題**

`force-cache` はリバリデーション期間を指定しないと Next.js のデータキャッシュに永続的に保存されます。`year` が現在の年の場合（例：2026年中に呼び出されると）、年の途中で新しいコミットが追加されても最初に取得したレスポンスが永遠にキャッシュされ続けます。PR 説明では「過去の不変データ」と述べていますが、この関数は過去年だけでなく現在進行中の年にも呼ばれます。過去年のみに `force-cache` を適用するか、`{ next: { revalidate: 3600 } }` などの TTL を設定する形を検討してください。

How can I resolve this? If you propose a fix, please make it concise.

@greptile-apps greptile-apps Bot Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 security 認証トークンがキャッシュキーに含まれないセキュリティ問題

Next.js のデータキャッシュ（force-cache）は Authorization などのリクエストヘッダーをキャッシュキーに含めません。キャッシュキーはリクエスト URL のみです。もし複数ユーザーが同じ owner/repo をトップリポジトリとして持つ場合、ユーザー A のトークンで取得したプライベートリポジトリのコミット一覧がキャッシュされ、本来アクセス権を持たないユーザー B が同じ URL をリクエストするとキャッシュされたレスポンス（ユーザー A のデータ）が返される可能性があります。no-store に戻すか、認証付きリクエストへのキャッシュ適用を慎重に検討してください。

Prompt To Fix With AI 
This is a comment left during a code review.
Path: src/lib/githubYearInReview.ts
Line: 319

Comment:
**認証トークンがキャッシュキーに含まれないセキュリティ問題**

Next.js のデータキャッシュ（`force-cache`）は `Authorization` などのリクエストヘッダーをキャッシュキーに含めません。キャッシュキーはリクエスト URL のみです。もし複数ユーザーが同じ `owner/repo` をトップリポジトリとして持つ場合、ユーザー A のトークンで取得したプライベートリポジトリのコミット一覧がキャッシュされ、本来アクセス権を持たないユーザー B が同じ URL をリクエストするとキャッシュされたレスポンス（ユーザー A のデータ）が返される可能性があります。`no-store` に戻すか、認証付きリクエストへのキャッシュ適用を慎重に検討してください。

How can I resolve this? If you propose a fix, please make it concise.

if (res.status === 403) {
handleRateLimit(res);
}
Expand Down
Loading