lightinig-bounties - #163
Conversation
|
Someone is attempting to deploy a commit to the Threadflow Team on Vercel. A member of the Team first needs to authorize it. |
|
@rosemary21 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 20 minutes and 8 seconds. ⌛ 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. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds a Lightning Rounds feature: new landing page, banner, schedule widget, bounty-card badge, and hooks for round aggregation and countdown; integrates banner/schedule into existing bounty pages and provides client-side countdowns and per-round bounty grouping. Changes
Sequence DiagramssequenceDiagram
participant User
participant Page as Lightning Round Page
participant Hooks as useLightningRounds / useLightningRoundBounties
participant Query as GraphQL Query
participant Countdown as useCountdown
User->>Page: Navigate to /bounty/lightning-round (optional windowId)
Page->>Hooks: useLightningRounds()
Hooks->>Query: useActiveBountiesQuery()
Query-->>Hooks: Active bounties with bountyWindow info
Hooks->>Hooks: Group by window, compute rounds & activeRound
Hooks-->>Page: rounds[], activeRound
Page->>Hooks: useLightningRoundBounties(windowId)
Hooks->>Query: useBountiesQuery(windowId, limit=50)
Query-->>Hooks: Bounties for window
Hooks->>Hooks: Bucket by category, calc totals, completedCount
Hooks-->>Page: bounties, byCategory, totals
Page->>Countdown: useCountdown(targetDate)
Countdown->>Countdown: tick every second
Countdown-->>Page: days,hours,minutes,seconds,expired
Page-->>User: Render categories, stats, progress bar, and countdown
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
components/bounty/bounty-card.tsx (1)
112-117: Consider displaying round name or checking round status.The implementation correctly shows the Lightning badge when
bountyWindowexists. Two optional enhancements to consider:
- The
bountyWindow.namefield is available (per the GraphQL fragment) and could replace the static "Lightning" text to show the actual round name.- The badge displays regardless of
bountyWindow.status— a completed or cancelled round will still show the badge. If the intent is to highlight only active lightning rounds, consider checkingbountyWindow.status === 'ACTIVE'.These are optional improvements; the current implementation meets the basic acceptance criteria.
💡 Optional: Show round name and check status
- {bounty.bountyWindow && ( + {bounty.bountyWindow && bounty.bountyWindow.status === 'ACTIVE' && ( <Badge className="text-[10px] px-1.5 py-0.5 gap-1 bg-yellow-500/15 text-yellow-400 border-yellow-500/30"> <Zap className="h-2.5 w-2.5 fill-yellow-400" /> - Lightning + {bounty.bountyWindow.name} </Badge> )}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/bounty/bounty-card.tsx` around lines 112 - 117, The badge currently renders whenever bounty.bountyWindow is truthy and shows static "Lightning"; update the JSX in the component that renders Badge (the block using Badge and Zap) to instead display bounty.bountyWindow.name when available and to only render the Badge for active rounds by checking bounty.bountyWindow.status === 'ACTIVE' (fall back to the static label if name is missing). Keep the existing Badge and Zap usage but add the conditional on bounty.bountyWindow.status and replace the hardcoded text with bounty.bountyWindow.name || 'Lightning'.app/bounty/lightning-round/page.tsx (2)
255-258: Label mismatch for ended rounds.The label shows "Starts in" when
isActiveis false, but this includes ended rounds. Consider adjusting the label logic to avoid showing a countdown label at all for ended rounds.Proposed fix
- <CountdownBlock - targetDate={countdownTarget ?? null} - label={isActive ? "Ends in" : "Starts in"} - /> + {!isEnded && ( + <CountdownBlock + targetDate={countdownTarget ?? null} + label={isActive ? "Ends in" : "Starts in"} + /> + )}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/bounty/lightning-round/page.tsx` around lines 255 - 258, The current CountdownBlock is given label based only on isActive which causes ended rounds (isActive false but past targetDate) to show "Starts in"; update the logic around CountdownBlock/props (CountdownBlock, targetDate, label, countdownTarget, isActive) to detect an ended round and either omit the label or skip rendering the component: e.g., compute an isEnded check (targetDate in the past) and then pass label={isActive ? "Ends in" : (isEnded ? undefined : "Starts in")} or conditionally render CountdownBlock only when not ended so ended rounds do not display a countdown label.
179-186: Countdown may show "Starts in" for already-ended rounds.When a round has ended (
isEndedis true) but its status is not"active", the code setscountdownTargettostartDateand displays "Starts in". This will show a confusing countdown for a past date (whichuseCountdownwill mark as expired, returning null). WhileCountdownBlockhandlesexpiredby returning null, the label "Starts in" is still set—this is potentially misleading if there's any race condition or the countdown hasn't yet recalculated.Consider explicitly handling the ended state:
Proposed fix
const isActive = currentRound?.status.toLowerCase() === "active"; const isEnded = currentRound?.endDate && new Date(currentRound.endDate) < new Date(); - const countdownTarget = isActive ? currentRound?.endDate : currentRound?.startDate; + const countdownTarget = isActive + ? currentRound?.endDate + : isEnded + ? null + : currentRound?.startDate;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/bounty/lightning-round/page.tsx` around lines 179 - 186, The countdown can show a "Starts in" label for already-ended rounds because countdownTarget is set to startDate when isActive is false; update the logic that computes countdownTarget (and any label selection) in the component using currentRound, isActive and isEnded so that when isEnded is true you set countdownTarget to null/undefined (or otherwise skip rendering the CountdownBlock) instead of using currentRound.startDate; change the assignment of countdownTarget and any related label computation (references: isActive, isEnded, countdownTarget, currentRound, useCountdown, CountdownBlock) so ended rounds do not render a "Starts in" countdown.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hooks/use-lightning-rounds.ts`:
- Around line 83-86: The hook useLightningRoundBounties currently calls
useBountiesQuery with query: { bountyWindowId: windowId, limit: 50 } even when
windowId is empty, causing unnecessary requests; update the call to pass an
enabled flag (e.g., enabled: Boolean(windowId)) so the query is skipped when
windowId is falsy, and keep the query object intact (bountyWindowId and limit)
to preserve behavior when enabled.
---
Nitpick comments:
In `@app/bounty/lightning-round/page.tsx`:
- Around line 255-258: The current CountdownBlock is given label based only on
isActive which causes ended rounds (isActive false but past targetDate) to show
"Starts in"; update the logic around CountdownBlock/props (CountdownBlock,
targetDate, label, countdownTarget, isActive) to detect an ended round and
either omit the label or skip rendering the component: e.g., compute an isEnded
check (targetDate in the past) and then pass label={isActive ? "Ends in" :
(isEnded ? undefined : "Starts in")} or conditionally render CountdownBlock only
when not ended so ended rounds do not display a countdown label.
- Around line 179-186: The countdown can show a "Starts in" label for
already-ended rounds because countdownTarget is set to startDate when isActive
is false; update the logic that computes countdownTarget (and any label
selection) in the component using currentRound, isActive and isEnded so that
when isEnded is true you set countdownTarget to null/undefined (or otherwise
skip rendering the CountdownBlock) instead of using currentRound.startDate;
change the assignment of countdownTarget and any related label computation
(references: isActive, isEnded, countdownTarget, currentRound, useCountdown,
CountdownBlock) so ended rounds do not render a "Starts in" countdown.
In `@components/bounty/bounty-card.tsx`:
- Around line 112-117: The badge currently renders whenever bounty.bountyWindow
is truthy and shows static "Lightning"; update the JSX in the component that
renders Badge (the block using Badge and Zap) to instead display
bounty.bountyWindow.name when available and to only render the Badge for active
rounds by checking bounty.bountyWindow.status === 'ACTIVE' (fall back to the
static label if name is missing). Keep the existing Badge and Zap usage but add
the conditional on bounty.bountyWindow.status and replace the hardcoded text
with bounty.bountyWindow.name || 'Lightning'.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 15eb379c-b598-49ee-8995-7de9514ad08b
📒 Files selected for processing (6)
app/bounty/lightning-round/page.tsxapp/bounty/page.tsxcomponents/bounty/bounty-card.tsxcomponents/bounty/lightning-round-banner.tsxcomponents/bounty/lightning-round-schedule.tsxhooks/use-lightning-rounds.ts
There was a problem hiding this comment.
Hi @rosemary21 , great work on the Lightning Rounds feature,
There are a few things to address before merging:
The useLightningRoundBounties hook fires a query even when windowId is empty, so it should include enabled: !!windowId as suggested.
Both useLightningRounds and useLightningRoundBounties redundantly fetch bounties for the same window on the lightning round page, which leads to unnecessary data duplication.
The b.status === "completed" check in the hook is case-sensitive, while the rest of the codebase uses .toLowerCase(), so the completed count will likely always be 0.
Additionally, please address the following:
The light mode compatibility needs attention, as the text-yellow-300 countdown text and from-yellow-950/40 gradients will have poor contrast or appear muddy on light backgrounds.
Fix the PR title typo (lightinig → lightning).
Add a Suspense boundary around useSearchParams() as required by Next.js 13+.
Apply the suggested correction for handling the empty windowId query and fix conflict.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/bounty/filters-sidebar.tsx`:
- Around line 212-214: The LightningRoundSchedule component currently renders an
empty-state when the rounds query fails; update
components/bounty/lightning-round-schedule.tsx to explicitly handle the query
error by checking the query's isError (or error) state from whatever data hook
(e.g., useRounds or useQuery) you use, and add an error UI branch that shows a
clear error message plus a retry action that calls the query's refetch (or
retry) method; ensure the component still handles loading and success branches
but returns the new error view when isError is true so the sidebar (where
LightningRoundSchedule is mounted) won’t display the misleading empty state.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2756d2da-4797-41b3-a64f-0447ac935a0b
📒 Files selected for processing (3)
app/bounty/page.tsxcomponents/bounty/bounty-card.tsxcomponents/bounty/filters-sidebar.tsx
✅ Files skipped from review due to trivial changes (2)
- app/bounty/page.tsx
- components/bounty/bounty-card.tsx
- Skip useLightningRoundBounties query when windowId is empty (avoids unnecessary request on initial load before a round is selected) - Normalize status case in completedCount filter so "COMPLETED" from the backend is counted correctly - Extract hardcoded bounties limit (50) to LIGHTNING_ROUND_BOUNTIES_LIMIT - Replace eslint-disable in useCountdown with useCallback so getTime stays stable and the effect deps are correct - Handle LightningRoundSchedule query failures with an explicit error branch and a retry button instead of the misleading empty state - Wrap useSearchParams in a Suspense boundary as required by Next.js 13+ Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 participants
closes #145
Summary by CodeRabbit