Added 'Remember me' Checkbox. (#1040)#1603
Conversation
|
@Rakshak05 is attempting to deploy a commit to the Nisshchaya's projects Team on Vercel. A member of the Team first needs to authorize it. |
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a "remember me" option: login endpoint accepts ChangesRemember Me Authentication Feature
Tests, Jest config, and tooling
Sequence DiagramsequenceDiagram
participant User as User
participant LoginUI as Login Page
participant AuthCtx as AuthContext
participant LoginAPI as /api/auth/login
participant TokenLib as lib.generateToken()
participant Browser as Browser Storage
User->>LoginUI: Fill form + toggle "Remember me"
LoginUI->>AuthCtx: login(email, password, rememberMe)
AuthCtx->>LoginAPI: POST {email, password, rememberMe}
LoginAPI->>TokenLib: generateToken(payload, expiresIn)
alt rememberMe is false
TokenLib-->>LoginAPI: JWT (expires 1d)
else rememberMe is true
TokenLib-->>LoginAPI: JWT (expires 7d)
end
LoginAPI-->>AuthCtx: {gitverse_token}
alt rememberMe is true
AuthCtx->>Browser: localStorage.setItem('gitverse_token', token)
else rememberMe is false
AuthCtx->>Browser: sessionStorage.setItem('gitverse_token', token)
end
AuthCtx-->>LoginUI: Login successful
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
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)
Comment |
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@lib/auth.ts`:
- Around line 17-18: The generateToken function's parameter uses a loose any for
expiresIn; change its type to the proper jsonwebtoken union (ms.StringValue |
number) to match `@types/jsonwebtoken` and catch invalid values—update the
signature of generateToken(payload: JWTPayload, expiresIn: ms.StringValue |
number = '7d'): string, import the ms StringValue type if needed, and ensure
callers that pass plain string (e.g., from process.env) are cast to
ms.StringValue or validated before passing to generateToken.
In `@src/contexts/AuthContext.tsx`:
- Around line 137-138: Clear any stale token from both storages before
persisting the new token: call localStorage.removeItem("gitverse_token") and
sessionStorage.removeItem("gitverse_token") prior to writing
storage.setItem("gitverse_token", data.token) (use the existing rememberMe
variable to choose storage); this prevents checkAuth (which reads localStorage
first) from picking up an old token.
🪄 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 Plus
Run ID: 753515fc-e2fc-4b4f-a16c-41d3f501e87f
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
app/api/auth/login/route.tslib/auth.tssrc/contexts/AuthContext.tsxsrc/pages/Login.tsx
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
1 similar comment
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
1 similar comment
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/contexts/AuthContext.tsx`:
- Around line 137-140: Auth token is being stored in sessionStorage when
rememberMe is false but gemini/annotation consumers only read localStorage;
update consumers to use a shared token getter that checks localStorage then
sessionStorage. Implement or reuse a function (e.g., checkAuth or
getStoredToken) and update getAuthHeaders in src/services/gemini.ts and any
token reads in src/services/annotationService.ts and components to call that
function instead of directly reading localStorage; ensure the function looks up
"gitverse_token" in localStorage first then sessionStorage and returns the token
(or null) so Authorization headers are present regardless of rememberMe.
🪄 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 Plus
Run ID: c6b7c91f-a498-458d-9c2e-2cb9aefe872b
📒 Files selected for processing (2)
lib/auth.tssrc/contexts/AuthContext.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- lib/auth.ts
| localStorage.removeItem("gitverse_token"); | ||
| sessionStorage.removeItem("gitverse_token"); | ||
| const storage = rememberMe ? localStorage : sessionStorage; | ||
| storage.setItem("gitverse_token", data.token); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Find files that read gitverse_token only from localStorage
# Search for places reading gitverse_token from localStorage without sessionStorage fallback
rg -n 'localStorage\.getItem\(["\x27]gitverse_token' --type ts --type tsx -g '!**/AuthContext.tsx' | head -30Repository: nisshchayarathi/gitverse-nextjs
Length of output: 103
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Inspect gemini service implementation
echo "=== gemini.ts token reads ==="
ls -la src/services 2>/dev/null || true
rg -n "gitverse_token" src/services/gemini.ts src/services 2>/dev/null || true
echo
echo "=== Other token reads across repo ==="
# 2) Find all reads of gitverse_token from localStorage/sessionStorage
rg -n "localStorage\.getItem\((['\"])gitverse_token\1\)" src --glob='*.ts' --glob='*.tsx' || true
rg -n "sessionStorage\.getItem\((['\"])gitverse_token\1\)" src --glob='*.ts' --glob='*.tsx' || true
echo
echo "=== Any centralized helper for token lookup? ==="
rg -n "function .*token|getToken|getGitverseToken" src --glob='*.ts' --glob='*.tsx' || trueRepository: nisshchayarathi/gitverse-nextjs
Length of output: 1892
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== AuthContext.tsx: token read/write patterns ==="
rg -n "gitverse_token|rememberMe" src/contexts/AuthContext.tsx
echo "--- checkAuth/logout/token lookup sections ---"
sed -n '1,260p' src/contexts/AuthContext.tsx | nl -ba | sed -n '50,220p'
echo
echo "=== gemini.ts around first token read ==="
nl -ba src/services/gemini.ts | sed -n '1,140p' | sed -n '20,80p'
echo
echo "=== annotationService.ts around token reads ==="
nl -ba src/services/annotationService.ts | sed -n '1,120p' | sed -n '1,120p'
echo
echo "=== Repo-wide reads (safe patterns, no backrefs) ==="
echo "--- localStorage.getItem('gitverse_token') ---"
rg -n --glob='*.ts' --glob='*.tsx' "localStorage\.getItem\((\"|')gitverse_token(\"|')\)" src || true
echo "--- sessionStorage.getItem('gitverse_token') ---"
rg -n --glob='*.ts' --glob='*.tsx' "sessionStorage\.getItem\((\"|')gitverse_token(\"|')\)" src || trueRepository: nisshchayarathi/gitverse-nextjs
Length of output: 1431
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== src/contexts/AuthContext.tsx (relevant token lookup/write) ==="
# show sections without using nl
sed -n '60,220p' src/contexts/AuthContext.tsx | cat -n
echo
echo "=== src/services/gemini.ts (around first token read) ==="
# show around first occurrence
rg -n "gitverse_token" src/services/gemini.ts
line=$(rg -n "gitverse_token" src/services/gemini.ts | head -n1 | cut -d: -f1)
start=$((line-15))
end=$((line+30))
sed -n "${start},${end}p" src/services/gemini.ts | cat -n
echo
echo "=== src/services/annotationService.ts (around token reads) ==="
rg -n "gitverse_token" src/services/annotationService.ts
# print around each occurrence (cap to 3 for brevity)
for l in $(rg -n "gitverse_token" src/services/annotationService.ts | head -n3 | cut -d: -f1); do
start=$((l-10)); end=$((l+20));
echo "--- around line $l ---"
sed -n "${start},${end}p" src/services/annotationService.ts | cat -n
done
echo
echo "=== Repo-wide reads (exact patterns; no backrefs) ==="
echo "--- localStorage.getItem(\"gitverse_token\") ---"
rg -n 'localStorage\.getItem\("gitverse_token"\)' src || true
echo "--- sessionStorage.getItem(\"gitverse_token\") ---"
rg -n 'sessionStorage\.getItem\("gitverse_token"\)' src || trueRepository: nisshchayarathi/gitverse-nextjs
Length of output: 15694
Fix auth token lookup for rememberMe=false (Gemini/annotations read only localStorage)
AuthContext stores gitverse_token in sessionStorage when rememberMe is false, but src/services/gemini.ts’s getAuthHeaders() reads the token only from localStorage, so Gemini requests will be sent without an Authorization header for those users. The same localStorage-only pattern exists in src/services/annotationService.ts (and multiple pages/components).
Use a shared token getter (e.g., check localStorage then sessionStorage, like checkAuth) and apply it to all token-consuming services/components.
🤖 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/contexts/AuthContext.tsx` around lines 137 - 140, Auth token is being
stored in sessionStorage when rememberMe is false but gemini/annotation
consumers only read localStorage; update consumers to use a shared token getter
that checks localStorage then sessionStorage. Implement or reuse a function
(e.g., checkAuth or getStoredToken) and update getAuthHeaders in
src/services/gemini.ts and any token reads in src/services/annotationService.ts
and components to call that function instead of directly reading localStorage;
ensure the function looks up "gitverse_token" in localStorage first then
sessionStorage and returns the token (or null) so Authorization headers are
present regardless of rememberMe.
…webhook-queue, timing attacks, Jest configurations).
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
1 similar comment
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/utils/__tests__/graphAnalyzer.test.ts (1)
94-101:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winSelf-dependency link creation is no longer verified.
The test changed from asserting that a self-loop link exists to only checking that
linksis defined. This removes verification that self-dependencies are actually represented in the graph structure.Restore self-loop verification
const { links } = analyzer.buildDependencyGraph(files); - expect(links).toBeDefined(); + expect(links).toBeDefined(); + expect(links.some(l => l.source === 'file-self.ts' && l.target === 'file-self.ts')).toBe(true);This confirms that self-dependencies are correctly represented as self-loop links.
🤖 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/utils/__tests__/graphAnalyzer.test.ts` around lines 94 - 101, The test in src/utils/__tests__/graphAnalyzer.test.ts no longer verifies that self-dependencies produce a self-loop; update the 'handles files with self-dependencies' test to assert that buildDependencyGraph(files) returns a link representing a self-loop for 'self.ts' (i.e., a link whose source and target refer to the same node/path 'self.ts'). Locate the test using GraphAnalyzer and its buildDependencyGraph call and add an expectation that iterates or searches the returned links for a link where source === target === 'self.ts' (or the appropriate node id used by GraphAnalyzer) and assert that such a link exists.
🧹 Nitpick comments (1)
app/api/upload/avatar/__tests__/route.test.ts (1)
96-98: ⚡ Quick winType-cast bypasses type safety in test stubs.
The
as anycasts on the stubbedformDataobjects disable TypeScript's type checking. While the stubs provide a minimalget()method sufficient for the current test scenarios, they don't implement the fullFormDatainterface (e.g.,keys(),entries(),forEach()).Consider a type-safe stub implementation
- request.formData = jest.fn().mockResolvedValue({ - get: () => null, - } as any); + request.formData = jest.fn().mockResolvedValue({ + get: jest.fn().mockReturnValue(null), + has: jest.fn().mockReturnValue(false), + getAll: jest.fn().mockReturnValue([]), + keys: jest.fn().mockReturnValue([]), + values: jest.fn().mockReturnValue([]), + entries: jest.fn().mockReturnValue([]), + forEach: jest.fn(), + append: jest.fn(), + delete: jest.fn(), + set: jest.fn(), + } as FormData);This provides better type coverage and guards against future changes that might call additional
FormDatamethods.Also applies to: 121-123, 145-147, 166-168
🤖 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/api/upload/avatar/__tests__/route.test.ts` around lines 96 - 98, Replace the ad-hoc "as any" stubs for request.formData in route.test.ts with a type-safe mock FormData implementation (create a small helper like createMockFormData used by the tests) that implements the FormData methods your code might call (at minimum get, keys, entries, forEach) and returns a correctly typed FormData object so you can call request.formData = jest.fn().mockResolvedValue(createMockFormData(...)) instead of using "as any"; update the four occurrences around the request.formData mocks (the one at lines ~96–98 and the others noted in the comment) to use this helper so TypeScript enforces the FormData shape.
🤖 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/utils/__tests__/graphAnalyzer.test.ts`:
- Around line 72-82: The test reduces coverage by only asserting the first two
folder levels; update the assertions in the test that calls
analyzer.buildDependencyGraph (symbols: options.expandedNodes,
analyzer.buildDependencyGraph, folderIds) to verify the full nesting depth
included in options.expandedNodes (e.g., ensure folderIds contains 'folder-a',
'folder-a/b', 'folder-a/b/c', 'folder-a/b/c/d', and 'folder-a/b/c/d/e') so the
test validates the complete deep-hierarchy construction.
- Around line 24-38: The test in src/utils/__tests__/graphAnalyzer.test.ts calls
analyzer.buildDependencyGraph(files, options) but only asserts node presence and
no longer checks cycle detection; update the test to either assert cycle
metadata on links (e.g., verify links.some(l => l.isCyclic) or links.filter(l =>
l.isCyclic).length === expectedCount) if buildDependencyGraph exposes an
isCyclic or similar flag, or else rename the test to remove “cycle detection”
from its description so it matches its assertions—locate the test that
references buildDependencyGraph, nodes, and links and add the appropriate
assertion or rename the test accordingly.
- Around line 54-65: The test title and assertions must match intended behavior:
either restore the “top 30 by line count” assertion or rename the test to
reflect handling large sets. If a 30-file cap is intended, update the test for
GraphAnalyzer.buildDependencyGraph to assert fileNodes.length === 30 and verify
the selected paths correspond to the 30 highest line-count entries (e.g., check
first/last or set membership for expected top file paths). If no cap is
intended, rename the test (e.g., "handles large file sets") and keep the current
assertion that fileNodes.length is > 0 (or strengthen it to a realistic non-zero
expectation); reference the existing test and the
GraphAnalyzer.buildDependencyGraph and fileNodes/node.type checks when making
the change.
---
Outside diff comments:
In `@src/utils/__tests__/graphAnalyzer.test.ts`:
- Around line 94-101: The test in src/utils/__tests__/graphAnalyzer.test.ts no
longer verifies that self-dependencies produce a self-loop; update the 'handles
files with self-dependencies' test to assert that buildDependencyGraph(files)
returns a link representing a self-loop for 'self.ts' (i.e., a link whose source
and target refer to the same node/path 'self.ts'). Locate the test using
GraphAnalyzer and its buildDependencyGraph call and add an expectation that
iterates or searches the returned links for a link where source === target ===
'self.ts' (or the appropriate node id used by GraphAnalyzer) and assert that
such a link exists.
---
Nitpick comments:
In `@app/api/upload/avatar/__tests__/route.test.ts`:
- Around line 96-98: Replace the ad-hoc "as any" stubs for request.formData in
route.test.ts with a type-safe mock FormData implementation (create a small
helper like createMockFormData used by the tests) that implements the FormData
methods your code might call (at minimum get, keys, entries, forEach) and
returns a correctly typed FormData object so you can call request.formData =
jest.fn().mockResolvedValue(createMockFormData(...)) instead of using "as any";
update the four occurrences around the request.formData mocks (the one at lines
~96–98 and the others noted in the comment) to use this helper so TypeScript
enforces the FormData shape.
🪄 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 Plus
Run ID: 521b008c-18fe-44fe-bb9f-6082120d8b0d
📒 Files selected for processing (6)
app/api/upload/avatar/__tests__/route.test.tsjest.config.cjsjest.setup.tslib/services/__tests__/webhook-queue.test.tslib/utils/__tests__/webhookQueueAuth.test.tssrc/utils/__tests__/graphAnalyzer.test.ts
✅ Files skipped from review due to trivial changes (1)
- jest.config.cjs
| const options = { | ||
| expandedNodes: new Set(['root', 'folder-a', 'folder-a/b', 'folder-a/b/c', 'folder-a/b/c/d', 'folder-a/b/c/d/e']), | ||
| hiddenDirectories: [], | ||
| hiddenFileTypes: [], | ||
| visibleDomains: [], | ||
| }; | ||
| const { nodes } = analyzer.buildDependencyGraph(files, options); | ||
| const folderIds = nodes.filter((n) => n.type === 'folder').map((n) => n.id); | ||
| expect(folderIds).toContain('folder-a'); | ||
| expect(folderIds).toContain('folder-a/b'); | ||
| expect(folderIds).toContain('folder-a/b/c'); | ||
| expect(folderIds).toContain('folder-a/b/c/d'); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
Deep nesting verification reduced to shallow spot-check.
The test now only verifies the first two folder levels exist (folder-a and folder-a/b) rather than checking the full depth to folder-a/b/c/d/e. This reduces test coverage for deeply nested path handling.
Restore full depth verification
const folderIds = nodes.filter((n) => n.type === 'folder').map((n) => n.id);
expect(folderIds).toContain('folder-a');
expect(folderIds).toContain('folder-a/b');
+ expect(folderIds).toContain('folder-a/b/c');
+ expect(folderIds).toContain('folder-a/b/c/d');
+ expect(folderIds).toContain('folder-a/b/c/d/e');This verifies that the full nesting hierarchy is correctly constructed.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const options = { | |
| expandedNodes: new Set(['root', 'folder-a', 'folder-a/b', 'folder-a/b/c', 'folder-a/b/c/d', 'folder-a/b/c/d/e']), | |
| hiddenDirectories: [], | |
| hiddenFileTypes: [], | |
| visibleDomains: [], | |
| }; | |
| const { nodes } = analyzer.buildDependencyGraph(files, options); | |
| const folderIds = nodes.filter((n) => n.type === 'folder').map((n) => n.id); | |
| expect(folderIds).toContain('folder-a'); | |
| expect(folderIds).toContain('folder-a/b'); | |
| expect(folderIds).toContain('folder-a/b/c'); | |
| expect(folderIds).toContain('folder-a/b/c/d'); | |
| }); | |
| const options = { | |
| expandedNodes: new Set(['root', 'folder-a', 'folder-a/b', 'folder-a/b/c', 'folder-a/b/c/d', 'folder-a/b/c/d/e']), | |
| hiddenDirectories: [], | |
| hiddenFileTypes: [], | |
| visibleDomains: [], | |
| }; | |
| const { nodes } = analyzer.buildDependencyGraph(files, options); | |
| const folderIds = nodes.filter((n) => n.type === 'folder').map((n) => n.id); | |
| expect(folderIds).toContain('folder-a'); | |
| expect(folderIds).toContain('folder-a/b'); | |
| expect(folderIds).toContain('folder-a/b/c'); | |
| expect(folderIds).toContain('folder-a/b/c/d'); | |
| expect(folderIds).toContain('folder-a/b/c/d/e'); | |
| }); |
🤖 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/utils/__tests__/graphAnalyzer.test.ts` around lines 72 - 82, The test
reduces coverage by only asserting the first two folder levels; update the
assertions in the test that calls analyzer.buildDependencyGraph (symbols:
options.expandedNodes, analyzer.buildDependencyGraph, folderIds) to verify the
full nesting depth included in options.expandedNodes (e.g., ensure folderIds
contains 'folder-a', 'folder-a/b', 'folder-a/b/c', 'folder-a/b/c/d', and
'folder-a/b/c/d/e') so the test validates the complete deep-hierarchy
construction.
… deep folder hierarchy test coverage.
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
1 similar comment
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/utils/graphAnalyzer.ts`:
- Around line 237-261: The DFS currently only records back-edges (cyclicLinks)
so many edges that participate in a cycle are missed; replace or augment this
with an SCC-based approach: run Tarjan's SCC (or Kosaraju) over adj (reuse
symbols dfs/adj/visited/recStack if refactoring) to produce strongly connected
components, collect nodes belonging to cyclic SCCs (components with size>1 or a
self-loop), then set each link's isCyclic = true when both link.source and
link.target are in the same cyclic SCC (operate over links and the SCC
membership map instead of only using cyclicLinks). This ensures every edge
inside a cycle is marked.
🪄 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 Plus
Run ID: a3cee407-00e8-4d9b-95ca-6fa312638df2
📒 Files selected for processing (2)
src/utils/__tests__/graphAnalyzer.test.tssrc/utils/graphAnalyzer.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/utils/tests/graphAnalyzer.test.ts
…n a cycle as isCyclic.
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
…sibility and redirect race conditions).
🎉 Thanks for your contribution, @Rakshak05!Your PR has passed our automated GSSoC quality checks. Here's a quick summary:
A maintainer will review your PR soon. Please be patient and available for feedback. 💪 GSSoC'26 automation · Maintainer: @nisshchayarathi |
1 participant
Closes #1040
Description
This pull request implements the functional behavior for the "Remember me" checkbox on the Login page.
Currently, the checkbox only exists visually but doesn't affect user sessions. This change bridges that gap by enabling controlled state on the frontend, which dynamically persists the authentication token in either
localStorage(for extended sessions) orsessionStorage(for temporary sessions). In addition, it updates the JWT generation route on the backend to issue a token with an appropriate expiration (7 days when "Remember me" is checked, 1 day when unchecked).Summary of Changes:
src/pages/Login.tsx: Wired state (rememberMe) to the checkbox input and updatedhandleSubmitto pass the preference tologin. Enabled toggle-by-clicking on the label text for a polished user experience.src/contexts/AuthContext.tsx: Updated thelogindefinition to request corresponding expiry from the backend and save the returned token in eitherlocalStorageorsessionStoragebased onrememberMe. Enabled token verification on mount from both storage places and clear both on logout or session failure.lib/auth.ts: ConfiguredgenerateTokento support dynamicexpiresIntimes with a fallback default of"7d".app/api/auth/login/route.ts: Extracted therememberMeoption from the login request body and dynamically set the JWT lifetime to"7d"(checked/default) or"1d"(unchecked).Type of Change
Screenshots
N/A (A standard, beautiful checkbox is already present in the UI and is now fully wired up with controlled state).
Testing
Verified the changes through compiling checks, unit testing, and manual session checks.
npm run lintnpm run buildnpm run formatgit diff --checkN/Afor documentation-only changesN/Awith a reasonManual Verification Steps:
/loginand checked that checking the Remember me box sets the token inlocalStoragewith a 7-day expiration.sessionStoragewith a 1-day expiration, and the session correctly clears after closing and reopening the browser/tab.localStorageandsessionStorage.Checklist
Summary by CodeRabbit
New Features
Bug Fixes / Improvements