Add org-code multi-management scoping and fix notification fan-out#40
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 27476629 | Triggered | Generic Password | 4c0eb46 | pages/LoginPage.tsx | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
|
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. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🔴 PaymentPage fetchData uses stale profile?.org_code due to missing dependency in useCallback
The fetchData callback in PaymentPage references profile?.org_code at line 40 but the useCallback dependency array at line 88 only includes [profile?.id]. This means the callback captures a stale closure over org_code.
Root Cause and Impact
At pages/PaymentPage.tsx:40, the function calls spotService.getUpcomingSpot(profile?.org_code), but the useCallback at pages/PaymentPage.tsx:88 has [profile?.id] as its only dependency. If profile.org_code changes (or is populated after initial render while profile.id stays the same), the memoized callback will use the old org_code value.
In practice, this means the PaymentPage could fetch spots from the wrong org or fail to filter by org at all, showing payments for spots from other organizations.
The other pages that were updated (HomePage, DrinksPage) correctly include profile?.org_code or profile in their dependency arrays, but PaymentPage was missed.
(Refers to line 88)
Was this helpful? React with 👍 or 👎 to provide feedback.
| // Fallback to mockApi for development | ||
| const { user: loggedInUser, profile: userProfile } = | ||
| await mockApi.login(identifier, password); | ||
| await mockApi.login(identifier, password, orgCode); | ||
|
|
||
| // If using mockApi, try to find the UUID in Supabase | ||
| try { |
There was a problem hiding this comment.
🔴 Login setLoading(false) never called when mockApi.login throws, leaving AuthContext permanently in loading state
In AuthContext.login, if the Supabase login fails (caught at line 96-98) and then mockApi.login at line 102 also throws (e.g., invalid credentials with wrong org code), the error propagates uncaught within the login function. The setLoading(false) at line 126 is never reached, leaving AuthContext.loading stuck as true.
Root Cause and Impact
The login function at contexts/AuthContext.tsx:57 calls setLoading(true) at line 58. The Supabase attempt is wrapped in try-catch (lines 60-98), but the mockApi.login call at line 102 and subsequent code (lines 100-126) are NOT in a try-catch. If mockApi.login throws "Invalid credentials", the error propagates to the caller.
While the caller (LoginPage.handleLogin) catches the error in its own try-catch and resets its local loading state, the AuthContext.loading remains true forever. This was a pre-existing issue, but this PR makes it significantly more likely to trigger: the new orgCode filter means mockApi.login will throw more often (e.g., when a user enters the wrong org code), since the mock login now checks (!orgCode?.trim() || u.org_code === orgCode.trim()) at services/mockApi.ts:332.
Impact: After a failed login attempt, AuthContext.loading stays true, which could disable UI elements or cause other components that depend on this state to behave incorrectly.
(Refers to lines 100-127)
Prompt for agents
In contexts/AuthContext.tsx, the login function (lines 57-127) needs to ensure setLoading(false) is always called, even when mockApi.login throws. Wrap lines 100-126 (the mockApi fallback and subsequent code) in a try-catch-finally, or better yet, wrap the entire login function body in a try-finally block. For example, change the structure so that setLoading(false) is in a finally block at the outermost level of the login function:
const login = async (identifier: string, password: string, orgCode?: string) => {
setLoading(true);
try {
// ... existing Supabase login attempt ...
// ... existing mockApi fallback ...
} catch (err) {
// re-throw so callers can handle
throw err;
} finally {
setLoading(false);
}
};
Note: you need to remove the existing setLoading(false) calls at lines 93 and 126 and consolidate them into the single finally block.
Was this helpful? React with 👍 or 👎 to provide feedback.
Motivation
Org Code) only sees and receives notifications for their org, and ensure notification fan-out reliably reaches all users in the org.Description
org_codeandmanagement_nametoUserProfileandSpotintypes.tsand added a migrationsupabase_migration_orgs.sqlto add/index/backfill these columns and enforce a 4-digit org-code format.AuthContext.loginnow accepts an optionalorgCodeand Supabase/mock auth are filtered byprofiles.org_code, andLoginPagecollectsOrg Code(4 digits) for login andmanagementName+orgCodeduring mobile setup.spotService.getUpcomingSpot/getUpcomingSpots/getPastSpotsaccept an optionalorgCodefilter andcreateSpotpersistsorg_code, and pages that fetch spots (HomePage,DrinksPage,DrinksPageNew,PaymentPage) now passprofile?.org_codewhen callinggetUpcomingSpot.notificationService.createNotificationForAllUsersnow accepts an optionalorgCodeand only inserts notifications for users in that org; Home page and real-time handlers pass the current user's org code when broadcasting spot/create/update/delete/RSVP messages.services/mockApi.tsupdated to includeorg_code/management_nameon mock users and to respectorgCodeduring mock login;profileService.createProfilepersists org metadata.Testing
npm run buildsuccessfully (production build completed without errors).vite) and verified the updated login UI (Org Code field) by capturing a screenshot of the running app (screenshot produced).npm run buildalso succeeded).Codex Task