feat: Add daily GitHub activity reminders and streak tracking#535
Conversation
✅ Deploy Preview for github-spy ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
More reviews will be available in 27 minutes and 21 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR implements a daily activity tracking feature that fetches GitHub contribution metrics (commits, PRs, issues, and a 7-day streak) and displays motivational reminders on the Tracker dashboard. The ChangesDaily Activity Status
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🎉 Thank you @codedbydollys10 for your contribution. Please make sure your PR follows https://github.com/GitMetricsLab/github_tracker/blob/main/CONTRIBUTING.md#-pull-request-guidelines
|
hey @mehul-m-prajapati pls check my pr and review it |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/hooks/useGitHubData.ts (1)
292-294:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winReset daily activity loading state when a new fetch starts.
A new fetch starts at Line 292, but
dailyActivityLoadedisn’t reset. The UI can temporarily show stale daily status for a previous request/user.Suggested fix
setLoading(true); setError(''); + setDailyActivityLoaded(false);Also applies to: 273-273
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/hooks/useGitHubData.ts` around lines 292 - 294, When starting a new GitHub fetch in useGitHubData (where you call setLoading(true) and setError('')), also reset the dailyActivityLoaded flag to false so stale daily activity isn’t shown; update the same two start-of-fetch sites that call setLoading/setError (the one that currently calls setLoading(true); setError('') and the other similar call) to call setDailyActivityLoaded(false) immediately when the new fetch begins, ensuring you still set it true only after fresh daily activity is successfully loaded.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/hooks/useGitHubData.ts`:
- Around line 42-43: getDateKey currently uses date.toISOString() (UTC) which
can flip the day near local midnight; replace its implementation to produce a
local YYYY-MM-DD string using date.getFullYear(), date.getMonth()+1 and
date.getDate() with zero-padding so keys reflect the local day; update the other
occurrence that also uses toISOString (the instance referenced around line 217)
to use the same local-date key helper or identical logic to avoid timezone drift
for “today” reminders/streaks.
- Around line 165-167: The current catch blocks in src/hooks/useGitHubData.ts
(the try/catch that returns 0 at the end of the daily activity computation)
swallow errors and convert API failures into a fake "0" activity; change those
catch blocks to propagate failure (either rethrow the caught error or return a
distinct "unavailable" sentinel such as null/undefined) instead of returning 0,
and update any callers of the function (e.g., the hook function that calls the
daily-activity computation) to treat null/undefined as "activity unavailable"
(showing an error state or retry) rather than "no activity"; specifically modify
the catch at the end of the function(s) involved (the catch that currently
returns 0 at lines shown) to throw the caught error or return null and ensure
downstream code in useGitHubData hook handles that sentinel appropriately.
- Around line 230-234: The current getSearchCount call using the query
`commenter:${username} updated:>=${today}` can include issues updated today by
others and thus overcounts; change the logic in useGitHubData to fetch actual
comment objects and filter by comment creation time instead of relying on that
search query: use the octokit REST comment-listing endpoint (e.g.,
octokit.rest.issues.listCommentsForRepo or the appropriate list comments
endpoint for the scope you need) with the since/today parameter, then count only
comments where comment.user.login === username and new Date(comment.created_at)
>= today; replace the getSearchCount call for “activity today” with this
comment-fetch-and-filter approach so the result strictly reflects comments the
user created today.
- Line 181: The forEach callback currently types the GitHub event as any; define
and use a narrow type (e.g. an interface or inline shape with at least `type:
string` and `created_at: string`) and replace `(event: any)` with that type in
the `response.data.forEach` call inside `useGitHubData`; update any local
variables that access `event.type` or `event.created_at` to use the new type so
the linter `@typescript-eslint/no-explicit-any` is satisfied and the streak logic
retains correct typings.
---
Outside diff comments:
In `@src/hooks/useGitHubData.ts`:
- Around line 292-294: When starting a new GitHub fetch in useGitHubData (where
you call setLoading(true) and setError('')), also reset the dailyActivityLoaded
flag to false so stale daily activity isn’t shown; update the same two
start-of-fetch sites that call setLoading/setError (the one that currently calls
setLoading(true); setError('') and the other similar call) to call
setDailyActivityLoaded(false) immediately when the new fetch begins, ensuring
you still set it true only after fresh daily activity is successfully loaded.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5c2d5873-3aa9-4e6a-b62e-83c4717bdb68
📒 Files selected for processing (3)
src/components/DailyActivityStatus.tsxsrc/hooks/useGitHubData.tssrc/pages/Tracker/Tracker.tsx
| } catch { | ||
| return 0; | ||
| } |
There was a problem hiding this comment.
Don’t convert daily-activity API failures into fake zero activity.
At Line 165 and Line 207, errors are swallowed and coerced to 0, which can incorrectly show “no activity” reminders when the real issue is API failure/permission/rate limit. Propagate failure and mark daily activity as unavailable instead of inactive.
Suggested fix
- ) => {
+ ): Promise<number> => {
try {
const response = await octokit.request(endpoint, {
q,
per_page: 1,
@@
- return response.data.total_count ?? 0;
- } catch {
- return 0;
+ return response.data.total_count ?? 0;
+ } catch (error) {
+ throw error;
}
};
@@
- ) => {
+ ): Promise<number> => {
try {
@@
- return streak;
- } catch {
- return 0;
+ return streak;
+ } catch (error) {
+ throw error;
}
};Also applies to: 207-209
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/hooks/useGitHubData.ts` around lines 165 - 167, The current catch blocks
in src/hooks/useGitHubData.ts (the try/catch that returns 0 at the end of the
daily activity computation) swallow errors and convert API failures into a fake
"0" activity; change those catch blocks to propagate failure (either rethrow the
caught error or return a distinct "unavailable" sentinel such as null/undefined)
instead of returning 0, and update any callers of the function (e.g., the hook
function that calls the daily-activity computation) to treat null/undefined as
"activity unavailable" (showing an error state or retry) rather than "no
activity"; specifically modify the catch at the end of the function(s) involved
(the catch that currently returns 0 at lines shown) to throw the caught error or
return null and ensure downstream code in useGitHubData hook handles that
sentinel appropriately.
| }); | ||
|
|
||
| const eventDates = new Set<string>(); | ||
| response.data.forEach((event: any) => { |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate file and print the relevant section around the referenced line.
ls -la src/hooks/useGitHubData.ts
nl -ba src/hooks/useGitHubData.ts | sed -n '150,230p'
# Also search for other explicit any occurrences in this file to gauge context.
rg -n ":\s*any\b|no-explicit-any|as\s+any\b|\bany\b" src/hooks/useGitHubData.tsRepository: GitMetricsLab/github_tracker
Length of output: 210
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Print lines 150-230 with line numbers via awk (nl is unavailable)
awk 'NR>=150 && NR<=230 {printf "%d\t%s\n", NR, $0}' src/hooks/useGitHubData.ts
# Search for explicit any (and likely no-explicit-any violations) in the file
rg -n "(:\s*)any\b|no-explicit-any|as\s+any\b|\bany\b" src/hooks/useGitHubData.tsRepository: GitMetricsLab/github_tracker
Length of output: 2400
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for existing types/interfaces mentioning events or GitHub event fields
rg -n "interface .*Event|type .*Event|created_at|PushEvent|PullRequestEvent|IssuesEvent|IssueCommentEvent|PullRequestReviewCommentEvent|PullRequestReviewEvent" src/hooks/useGitHubData.ts
# Show a bit more context around the streak function for any surrounding types/imports
awk 'NR>=120 && NR<=220 {printf "%d\t%s\n", NR, $0}' src/hooks/useGitHubData.tsRepository: GitMetricsLab/github_tracker
Length of output: 3022
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show imports/types at the top of the file (first ~120 lines)
awk 'NR>=1 && NR<=120 {printf "%d\t%s\n", NR, $0}' src/hooks/useGitHubData.ts
# Search for all streak-related access patterns
rg -n "fetchStreakFromEvents|created_at|event\.type|event\.created_at|GET /users/\\{username\\}/events" src/hooks/useGitHubData.tsRepository: GitMetricsLab/github_tracker
Length of output: 3673
Replace explicit any in GitHub event iteration with a typed event shape.
src/hooks/useGitHubData.ts line 181 uses response.data.forEach((event: any) => ...), violating @typescript-eslint/no-explicit-any; the streak logic only needs event.type and event.created_at.
Suggested fix
+type GitHubUserEvent = {
+ type: string;
+ created_at?: string;
+};
@@
- response.data.forEach((event: any) => {
+ response.data.forEach((event: GitHubUserEvent) => {🧰 Tools
🪛 ESLint
[error] 181-181: Unexpected any. Specify a different type.
(@typescript-eslint/no-explicit-any)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/hooks/useGitHubData.ts` at line 181, The forEach callback currently types
the GitHub event as any; define and use a narrow type (e.g. an interface or
inline shape with at least `type: string` and `created_at: string`) and replace
`(event: any)` with that type in the `response.data.forEach` call inside
`useGitHubData`; update any local variables that access `event.type` or
`event.created_at` to use the new type so the linter
`@typescript-eslint/no-explicit-any` is satisfied and the streak logic retains
correct typings.
| getSearchCount( | ||
| octokit, | ||
| 'GET /search/issues', | ||
| `commenter:${username} type:issue updated:>=${today}` | ||
| ), |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Search API qualifiers: Does commenter:USERNAME updated:>=YYYY-MM-DD mean the user commented on or after that date, or only that the issue was updated on that date by anyone? What is the correct qualifier/query to count issues commented by a user today?
💡 Result:
The GitHub Search API qualifier updated:>=YYYY-MM-DD refers to the date the issue or pull request was last updated by anyone [1]. It does not specifically filter for when the user commented; rather, it narrows the result set to issues or pull requests that have had any modification (including new comments, label changes, state changes, etc.) on or after the specified date [1]. Using commenter:USERNAME in combination with updated:>=YYYY-MM-DD will return issues where the user has commented AND the issue has been updated on or after the specified date [1]. There is no direct search qualifier in the GitHub Search API to filter specifically for when a comment was posted by a specific user. The GitHub Search API is designed to return issues or pull requests that match specific metadata, not individual comment timestamps. To find issues or pull requests where a user has commented today (2026-05-26), you can use: commenter:USERNAME updated:>=2026-05-26 Please note the following limitations: 1. This query will return all issues/PRs where the user has commented that were also updated by anyone today [1]. 2. Because the Search API does not index individual comment creation dates for filtering, this is the best available approximation to narrow your search to recent activity. 3. If you require a precise list of comments made by a user on a specific day, you must use the GitHub REST API or GraphQL API to fetch the user's event activity or repository-specific comments [2]. For example, the GET /users/{username}/events endpoint can be used to programmatically check for IssueCommentEvent activity occurring today.
Citations:
- 1: https://docs.github.com/en/enterprise/2.16/user/articles/searching-issues-and-pull-requests
- 2: https://docs.github.com/rest/issues/comments
🌐 Web query:
GitHub issue search qualifier commenter:semantics (does it require that user has commented?) and how it combines withupdated:; cite docs if available
💡 Result:
The GitHub search qualifier commenter: is used to filter issues and pull requests based on participation in the conversation [1]. Specifically, it matches issues or pull requests where the specified user has posted a comment [1]. Key semantic details include: - Requirement of Comment: The commenter: qualifier requires that the user has commented on the issue or pull request [1]. It generally excludes the original author of the issue if they have not added any subsequent comments [1]. - Interaction with Other Qualifiers: commenter: functions as a discrete filter [2]. It can be combined with other qualifiers like updated: in a standard AND-based search query [2]. For example, commenter:username updated:>2026-01-01 will return issues or pull requests where the user has commented and that have been updated since the specified date. - Comparison with involves:: While commenter: is strictly for comments, the involves: qualifier is broader; it matches issues or pull requests where a user was mentioned, assigned, or has commented [1]. If you want to include all instances of a user's activity regardless of whether they were the "author" or a "commenter," involves: is often a more comprehensive choice [1]. Qualifiers can be combined by simply separating them with spaces, which acts as a logical AND [3][2]. Any valid GitHub username, or @me for the authenticated user, can be used with commenter: [4][1].
Citations:
- 1: https://stackoverflow.com/questions/39568301/how-can-i-find-all-public-comments-for-a-github-user
- 2: https://github.com/github/docs/blob/main/content/rest/search/search.md
- 3: https://github.com/github/docs/blob/main/content/search-github/github-code-search/understanding-github-code-search-syntax.md
- 4: https://github.com/github/docs/blob/main/content/search-github/getting-started-with-searching-on-github/understanding-the-search-syntax.md
Fix “activity today” query semantics for GitHub Search (commenter: + updated:).
In src/hooks/useGitHubData.ts (lines ~230-234), commenter:${username} updated:>=${today} can count issues where the user commented at some point, but the issue was updated today by anyone—it does not guarantee the user’s comment happened “today”. If the acceptance criteria require “user commented today”, this query will overcount. Prefer fetching the user’s comment activity (e.g., via REST/GraphQL events or comment listing) and filtering by the comment created_at/date instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/hooks/useGitHubData.ts` around lines 230 - 234, The current
getSearchCount call using the query `commenter:${username} updated:>=${today}`
can include issues updated today by others and thus overcounts; change the logic
in useGitHubData to fetch actual comment objects and filter by comment creation
time instead of relying on that search query: use the octokit REST
comment-listing endpoint (e.g., octokit.rest.issues.listCommentsForRepo or the
appropriate list comments endpoint for the scope you need) with the since/today
parameter, then count only comments where comment.user.login === username and
new Date(comment.created_at) >= today; replace the getSearchCount call for
“activity today” with this comment-fetch-and-filter approach so the result
strictly reflects comments the user created today.
|
hey @mehul-m-prajapati review my PR. |
|
🎉🎉 Thank you for your contribution! Your PR #535 has been merged! 🎉🎉 |
2 participants
Related Issue
Description
Added a new Daily Activity Status feature to the GitHub Tracker dashboard to encourage consistent GitHub contributions through reminders and streak tracking.
Changes include:
Detect daily activity:
Added contribution streak calculation based on consecutive active days
Added dynamic motivational reminders, such as:
Added a new dashboard section displaying:
Integrated feature without affecting existing tracker functionality
How Has This Been Tested?
Tested manually for the following scenarios:
Screenshots (if applicable)
Before
After
Add screenshots showing:
Type of Change
Summary by CodeRabbit