Harden app global inbox lifecycle#334
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 20 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR adds a shared ChangesGlobal inbox shared resource store
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Screen
participant BeginRefreshAtom
participant API
participant ApplySuccessAtom
participant ApplyFailureAtom
participant SettleRefreshAtom
Screen->>BeginRefreshAtom: beginRefresh({ requestKey })
Screen->>API: fetch rows
alt success and not stale
API-->>Screen: rows
Screen->>ApplySuccessAtom: applySuccess({ rows, fetchedAt })
else failure and not stale
API-->>Screen: error
Screen->>ApplyFailureAtom: applyFailure({ message })
else stale request
Screen->>SettleRefreshAtom: settleRefresh({ requestKey })
end
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
app/stores/globalInbox.ts (1)
118-187: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winNotification and thread atom wiring is fully duplicated.
The four action atoms (
begin*,applySuccess*,applyFailure*,settle*) are mirrored line-for-line for notifications and threads, differing only in which resource atom and payload type they close over. A small generic factory would remove ~50 lines of duplication and reduce the surface for future divergence (e.g., the ownership-check fix above would otherwise need to be applied in four places instead of one).♻️ Proposed factory to eliminate duplication
+function createGlobalInboxActions<T>(resourceAtom: typeof globalNotificationResourceAtom) { + return { + begin: atom(null, (get, set, { requestKey }: BeginGlobalInboxRefreshInput) => { + set(resourceAtom, beginGlobalInboxRefresh(get(resourceAtom), requestKey)); + }), + applySuccess: atom(null, (_get, set, { value, updatedAt }: ApplyGlobalInboxSuccessInput<T>) => { + set(resourceAtom, applyGlobalInboxSuccess(value, updatedAt)); + }), + applyFailure: atom(null, (get, set, { error }: ApplyGlobalInboxFailureInput) => { + set(resourceAtom, applyGlobalInboxFailure(get(resourceAtom), error)); + }), + settle: atom(null, (get, set, { requestKey }: SettleGlobalInboxRefreshInput) => { + set(resourceAtom, settleGlobalInboxRefresh(get(resourceAtom), requestKey)); + }), + }; +}🤖 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 `@app/stores/globalInbox.ts` around lines 118 - 187, The notification and thread action atoms are duplicated across beginGlobalNotificationRefreshAtom, applyGlobalNotificationSuccessAtom, applyGlobalNotificationFailureAtom, settleGlobalNotificationRefreshAtom, and their globalThread* counterparts. Refactor this wiring into a small generic factory/helper that takes the resource atom and row type so the shared begin/applySuccess/applyFailure/settle logic lives in one place, reducing repeated code and keeping future behavior changes consistent.app/app/(main)/global-notifications.tsx (1)
94-147: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRefresh lifecycle duplicated with global-threads.tsx.
This
refreshcallback, the ref-sync effect, and the staleness-guard pattern are nearly identical toapp/app/(main)/global-threads.tsx(Lines 75-126 there), differing only in the fetch call, row-shaping, sort function, and error text. Consider extracting a shared hook (e.g.,useGlobalInboxRefresh(kind, fetchRows, sortRows, atoms)) parameterized by these differences to avoid maintaining two copies of the same lifecycle logic (including the request-key generation this logic relies on for staleness detection).🤖 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 `@app/app/`(main)/global-notifications.tsx around lines 94 - 147, The refresh lifecycle in global-notifications duplicates the same request-key, ref-sync, and staleness-guard flow used in global-threads, so it should be consolidated. Extract the shared logic from the refresh callback and related sync/guard behavior into a reusable hook or helper (for example, a useGlobalInboxRefresh-style abstraction) and parameterize only the differing parts such as the fetch call, row mapping, sort function, and error message. Keep the requestId/requestKey handling and stale-response checks centralized so both global-notifications and global-threads use the same implementation.
🤖 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.
Nitpick comments:
In `@app/app/`(main)/global-notifications.tsx:
- Around line 94-147: The refresh lifecycle in global-notifications duplicates
the same request-key, ref-sync, and staleness-guard flow used in global-threads,
so it should be consolidated. Extract the shared logic from the refresh callback
and related sync/guard behavior into a reusable hook or helper (for example, a
useGlobalInboxRefresh-style abstraction) and parameterize only the differing
parts such as the fetch call, row mapping, sort function, and error message.
Keep the requestId/requestKey handling and stale-response checks centralized so
both global-notifications and global-threads use the same implementation.
In `@app/stores/globalInbox.ts`:
- Around line 118-187: The notification and thread action atoms are duplicated
across beginGlobalNotificationRefreshAtom, applyGlobalNotificationSuccessAtom,
applyGlobalNotificationFailureAtom, settleGlobalNotificationRefreshAtom, and
their globalThread* counterparts. Refactor this wiring into a small generic
factory/helper that takes the resource atom and row type so the shared
begin/applySuccess/applyFailure/settle logic lives in one place, reducing
repeated code and keeping future behavior changes consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 20131900-5a46-4741-a518-14866651332d
📒 Files selected for processing (5)
app/app/(main)/global-notifications.tsxapp/app/(main)/global-threads.tsxapp/stores/globalInbox.test.tsapp/stores/globalInbox.tsdocs/core-sidecar-north-star.md
1 participant
Summary
Verification
Summary by CodeRabbit
New Features
Bug Fixes
Documentation