🧹 Refactor fetchUserProfile to use spread operator#456
Conversation
Co-authored-by: is0692vs <135803462+is0692vs@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request simplifies the fetchUserProfile function in src/lib/github.ts by replacing explicit property mapping with the spread operator (...profile). The reviewer correctly points out that using the spread operator leaks extra fields from the GitHub API response to the client, increasing the network payload size, and recommends reverting to explicit property selection.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| followers: profile.followers, | ||
| following: profile.following, | ||
| public_repos: profile.public_repos, | ||
| ...profile, |
There was a problem hiding this comment.
Using the spread operator ...profile will copy all properties from the actual runtime profile object returned by the GitHub API (such as id, node_id, html_url, repos_url, etc.) into the returned object. Since this object is serialized and sent to the client in the /api/dashboard/summary endpoint, this leaks unused fields and unnecessarily increases the network payload size. It is safer and more efficient to explicitly select only the required properties.
login: profile.login,
avatar_url: profile.avatar_url,
name: profile.name,
bio: profile.bio,
company: profile.company,
location: profile.location,
blog: profile.blog,
twitter_username: profile.twitter_username,
created_at: profile.created_at,
followers: profile.followers,
following: profile.following,
public_repos: profile.public_repos,
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ...profile, | ||
| orgs, | ||
| pinnedRepos, | ||
| }; |
There was a problem hiding this comment.
restGet は res.json() as Promise<T> でキャストしているだけで、ランタイムでは GitHub API の /users/:username レスポンス全体（id、node_id、email、html_url、public_gists、updated_at など 30 以上のフィールド）が profile オブジェクトに含まれます。TypeScript の型はコンパイル時しか保証せず、...profile を展開すると意図しないフィールドがすべて返り値に含まれてしまいます。変更前のコードは明示的に 12 フィールドを列挙することで許可リスト（allowlist）として機能していましたが、スプレッドによりその保護が失われています。email フィールドが公開設定のユーザーであれば、クライアントに意図せず露出する可能性があります。
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/lib/github.ts
Line: 242-245
Comment:
**スプレッド演算子によるランタイム余剰フィールドの流出**
`restGet` は `res.json() as Promise<T>` でキャストしているだけで、ランタイムでは GitHub API の `/users/:username` レスポンス全体（`id`、`node_id`、`email`、`html_url`、`public_gists`、`updated_at` など 30 以上のフィールド）が `profile` オブジェクトに含まれます。TypeScript の型はコンパイル時しか保証せず、`...profile` を展開すると意図しないフィールドがすべて返り値に含まれてしまいます。変更前のコードは明示的に 12 フィールドを列挙することで許可リスト（allowlist）として機能していましたが、スプレッドによりその保護が失われています。`email` フィールドが公開設定のユーザーであれば、クライアントに意図せず露出する可能性があります。
How can I resolve this? If you propose a fix, please make it concise.1 participant
🎯 What: Simplified
fetchUserProfileto use the spread operator for profile properties.💡 Why: Reduces duplication and improves readability.
✅ Verification: Ran
npm run testlocally and verified all tests pass.✨ Result: Improved maintainability of
fetchUserProfilefunction.PR created automatically by Jules for task 16208466654816058611 started by @is0692vs
Greptile Summary
fetchUserProfile関数の戻り値オブジェクト生成を、明示的なプロパティ列挙から...profileスプレッドに変更しています。コードの簡潔さは向上しますが、ランタイム挙動が変わります。restGet<GitHubUser>()はres.json() as Promise<T>を使っており、返るオブジェクトは型の保証なしに GitHub API レスポンス全体（id、node_id、email、public_gists、html_urlなど 30 以上のフィールド）を含みます。変更前の明示的列挙は allowlist として機能していましたが、スプレッドでその保護がなくなります。GitHubUser型とUserProfile型のフィールドセットは一致しているため TypeScript エラーは発生しませんが、ランタイムオブジェクトには型定義外のフィールドが混入します。Confidence Score: 3/5
スプレッド演算子によってランタイムで GitHub API の余剰フィールドが返り値に混入するため、そのままマージするのは避けるべきです。
restGetが型アサーションで GitHub API レスポンス全体を返すため、...profileはemailやidなどの意図しないフィールドをすべて呼び出し元に露出させます。変更前の明示的プロパティ列挙は allowlist として機能しており、その安全性の保証が失われています。src/lib/github.tsのfetchUserProfile関数（242〜245行目）Important Files Changed
fetchUserProfileの明示的プロパティ列挙をスプレッド演算子に置換。コンパイルは通るが、ランタイムでは GitHub API レスポンスの余剰フィールドが返り値に混入するリスクがある。Sequence Diagram
%%{init: {'theme': 'neutral'}}%% sequenceDiagram participant Caller participant fetchUserProfile participant fetchBasicProfile participant GitHub_API as GitHub REST API Caller->>fetchUserProfile: fetchUserProfile(username, token) fetchUserProfile->>fetchBasicProfile: fetchBasicProfile(username, token) fetchBasicProfile->>GitHub_API: GET /users/:username GitHub_API-->>fetchBasicProfile: 30+ fields (id, node_id, email, login, ...) fetchBasicProfile-->>fetchUserProfile: profile (typed as GitHubUser, but contains all API fields at runtime) Note over fetchUserProfile: Before: explicit 12-field allowlist After: ...profile spreads ALL runtime fields fetchUserProfile-->>Caller: UserProfile (+ unintended extra fields at runtime)%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% sequenceDiagram participant Caller participant fetchUserProfile participant fetchBasicProfile participant GitHub_API as GitHub REST API Caller->>fetchUserProfile: fetchUserProfile(username, token) fetchUserProfile->>fetchBasicProfile: fetchBasicProfile(username, token) fetchBasicProfile->>GitHub_API: GET /users/:username GitHub_API-->>fetchBasicProfile: 30+ fields (id, node_id, email, login, ...) fetchBasicProfile-->>fetchUserProfile: profile (typed as GitHubUser, but contains all API fields at runtime) Note over fetchUserProfile: Before: explicit 12-field allowlist After: ...profile spreads ALL runtime fields fetchUserProfile-->>Caller: UserProfile (+ unintended extra fields at runtime)Prompt To Fix All With AI
Reviews (1): Last reviewed commit: "🧹 Refactor fetchUserProfile to use spre..." | Re-trigger Greptile