feat: add key-based filter in OpenLake leaderboard#192
feat: add key-based filter in OpenLake leaderboard#192VarshiniGunti wants to merge 2 commits intoOpenLake:mainfrom
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
WalkthroughThis PR adds a key-based filtering feature to the OpenLake Leaderboard, enabling users to filter PR contributions by keys found in PR titles (e.g., Changes
Sequence DiagramsequenceDiagram
actor User
participant Frontend as OpenlakeTable
participant Backend as GithubOrganisationAPI
participant GitHub as GitHub API
User->>Frontend: Enter PR key & click Apply
Frontend->>Frontend: Update appliedPrKey state
Frontend->>Frontend: Trigger useEffect watching appliedPrKey
Frontend->>Backend: GET /leaderboard?pr_key=[key]
Backend->>Backend: _get_pr_key_contributions(key)
Backend->>GitHub: Query Issues API for PRs with key
GitHub-->>Backend: Return matching PRs
Backend->>Backend: Aggregate contributions by username
Backend-->>Frontend: Return sorted contributors list
Frontend->>Frontend: Update keyFilteredUsers state
Frontend->>Frontend: Set isFetchingPrKeyData = false
Frontend->>User: Display filtered contributors & applied key
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
app/src/components/OpenlakeTable.jsx (1)
151-183: Consolidate filtering effects to remove duplicated/stale state transitions.
Line 160-167filters withtodisplayusersimmediately aftersetTodisplayusers, thenLine 171-183repeats filtering again. This adds extra renders and transient stale updates.Proposed fix
useEffect(() => { if (showOLFriends) { setTodisplayusers( sourceUsers.filter((OLUser) => OLFriends.includes(OLUser.username)), ); } else { setTodisplayusers(sourceUsers); } - if (searchfield === "") { - setFilteredusers(todisplayusers); - } else { - setFilteredusers( - todisplayusers.filter((cfUser) => { - return cfUser.username - .toLowerCase() - .includes(searchfield.toLowerCase()); - }), - ); - } -}, [showOLFriends, OLFriends, searchfield, sourceUsers]); +}, [showOLFriends, OLFriends, sourceUsers]);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/src/components/OpenlakeTable.jsx` around lines 151 - 183, The two useEffect blocks duplicate filtering and cause transient stale state; replace them with a single useEffect that computes a local newTodisplay (based on showOLFriends, OLFriends, sourceUsers), calls setTodisplayusers(newTodisplay), then computes filtered = searchfield === "" ? newTodisplay : newTodisplay.filter(u => u.username.toLowerCase().includes(searchfield.toLowerCase())) and calls setFilteredusers(filtered); keep the dependency array [showOLFriends, OLFriends, searchfield, sourceUsers] and remove the second useEffect to avoid extra renders and stale reads of todisplayusers.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api/leaderboard/views.py`:
- Around line 177-178: The handler currently swallows non-200 GitHub responses
by breaking the loop when response.status_code != 200 and later always returning
HTTP 200, which masks upstream failures; update the logic around response (the
check using response.status_code) to propagate errors to the client instead of
treating them as "no results"—for non-200 responses return an appropriate error
response (use the actual response.status_code and include error details/body or
a clear message) or raise an HTTPException so callers can distinguish GitHub
failures from legitimately empty PR results; adjust the return path that
currently always returns 200 (the code after the loop that returns successful
results) to only return 200 on success.
- Around line 160-186: The loop in _get_pr_key_contributions currently counts
any PR whose title contains the key anywhere; update the per-item handling
inside the items loop to fetch the PR title (item.get("title")), trim leading
whitespace, and only increment contributions[username] if the trimmed title
starts with f'[{normalized_key}]' (otherwise continue); keep using the existing
contributions Counter and username extraction logic so only PRs with the key at
the title start are counted.
In `@app/src/components/OpenlakeTable.jsx`:
- Around line 127-149: The effect that fetches users for appliedPrKey (useEffect
→ getPrKeyFilteredUsers) can suffer stale-response races; fix it by creating an
AbortController (or a requestId token) inside the effect, pass controller.signal
to fetch, and on cleanup call controller.abort() so any previous fetch is
cancelled; ensure the catch distinguishes abort errors (don’t reset
keyFilteredUsers on abort) and still toggles setIsFetchingPrKeyData(false) in
finally so the state reflects the latest request.
---
Nitpick comments:
In `@app/src/components/OpenlakeTable.jsx`:
- Around line 151-183: The two useEffect blocks duplicate filtering and cause
transient stale state; replace them with a single useEffect that computes a
local newTodisplay (based on showOLFriends, OLFriends, sourceUsers), calls
setTodisplayusers(newTodisplay), then computes filtered = searchfield === "" ?
newTodisplay : newTodisplay.filter(u =>
u.username.toLowerCase().includes(searchfield.toLowerCase())) and calls
setFilteredusers(filtered); keep the dependency array [showOLFriends, OLFriends,
searchfield, sourceUsers] and remove the second useEffect to avoid extra renders
and stale reads of todisplayusers.
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.Unrecognized words (608)Some files were automatically ignored 🙈These sample patterns would exclude them: You should consider excluding directory paths (e.g. You should consider adding them to: File matching is via Perl regular expressions. To check these files, more of their words need to be in the dictionary than not. You can use To accept these unrecognized words as correct and update file exclusions, you could run the following commands... in a clone of the git@github.com:VarshiniGunti/Leaderboard-Pro.git repository curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/main/apply.pl' |
perl - 'https://github.com/OpenLake/Leaderboard-Pro/actions/runs/22404973202/attempts/1' &&
git commit -m 'Update check-spelling metadata'Available 📚 dictionaries could cover words not in the 📘 dictionary
Consider adding them (in with:
extra_dictionaries: |
cspell:django/dict/django.txt
cspell:software-terms/dict/softwareTerms.txt
cspell:python/src/common/extra.txt
cspell:npm/dict/npm.txt
cspell:html/dict/html.txtTo stop checking additional dictionaries, add (in check_extra_dictionaries: ""Warnings
|
| Count | |
|---|---|
| 15 | |
| 1 | |
| 5 | |
| 10 |
See
If you see a bunch of garbage
If it relates to a ...
well-formed pattern
See if there's a pattern that would match it.
If not, try writing one and adding it to the patterns.txt file.
Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.
Note that patterns can't match multiline strings.
binary-ish string
Please add a file path to the excludes.txt file instead of just accepting the garbage.
File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.
^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).
Feature: Key-Based Filter for OpenLake Leaderboard
Resolves #141
What this PR adds
This PR introduces a PR title key filter for the OpenLake leaderboard so contributors can be ranked by contributions tied to a specific initiative key, such as:
[FOSSOVERFLOW-2025][DEVLABS-2025]Highlights
pr_keyquery param:GET /openlake/?pr_key=FOSSOVERFLOW-2025FOSSOVERFLOW-2025) and instantly view contributions for PRs matching[KEY].Why this is useful
This enables event- and campaign-specific visibility, making it easy to analyze contributor activity for focused initiatives without affecting the default global leaderboard view.
Validation
Summary by CodeRabbit