feat: add community feed board UI and mock data integration#68
feat: add community feed board UI and mock data integration#68mithaliphadtare wants to merge 4 commits into
Conversation
|
@mithaliphadtare is attempting to deploy a commit to the karan3431's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
🎉 Thanks for your contribution, @mithaliphadtare! Please make sure CI passes and the checklist in the PR template is complete. A maintainer will review this soon. — The AgroNavis team |
|
Warning Review limit reached
More reviews will be available in 57 minutes and 34 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a full-stack community Q&A board feature. The backend reorganizes imports and introduces two Pydantic schemas ( ChangesCommunity Q&A Board
Frontend devDependency version updates
Sequence Diagram(s)sequenceDiagram
participant Browser as Browser (CommunityPage)
participant communityApi as communityApi utility
participant FastAPI as FastAPI Backend
participant Supabase
rect rgba(70, 130, 180, 0.5)
note over Browser,Supabase: Load Feed
Browser->>communityApi: getFeed()
communityApi->>FastAPI: GET /api/community/posts (Bearer token)
FastAPI->>Supabase: select posts (newest first)
FastAPI->>Supabase: select comments (oldest first)
Supabase-->>FastAPI: posts[], comments[]
FastAPI-->>communityApi: posts with nested comments[]
communityApi-->>Browser: Post[]
end
rect rgba(60, 179, 113, 0.5)
note over Browser,Supabase: Create Post
Browser->>communityApi: createPost(title, content, imageUrl)
communityApi->>FastAPI: POST /api/community/posts
FastAPI->>Supabase: insert into posts (user_id, title, content, image_url)
Supabase-->>FastAPI: inserted Post
FastAPI-->>communityApi: new Post
communityApi-->>Browser: Post
Browser->>communityApi: getFeed() (refresh)
end
rect rgba(210, 105, 30, 0.5)
note over Browser,Supabase: Create Comment
Browser->>communityApi: createComment(postId, content)
communityApi->>FastAPI: POST /api/community/comments
FastAPI->>Supabase: insert into comments (post_id, user_id, content)
Supabase-->>FastAPI: inserted Comment
FastAPI-->>communityApi: new Comment
communityApi-->>Browser: Comment
Browser->>communityApi: getFeed() (refresh)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (2 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: 6
🤖 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 `@backend/main.py`:
- Around line 864-865: The exception handlers in the code are exposing raw error
details to API clients by using str(e) directly in the HTTPException detail,
which creates a security vulnerability. Replace all instances where raw
exception strings are returned (in the except Exception as e blocks at lines
864-865, 880-881, and 895-896) with a generic message like "An error occurred"
or "Internal server error", and instead log the actual exception details using a
server-side logger so debugging information is available in logs but not exposed
to clients.
- Around line 852-862: The current implementation has O(posts × comments)
complexity because the nesting loop iterates through all_comments for every post
using a list comprehension. Build a dictionary index first that maps post_id to
a list of comments, then iterate through posts and assign comments using the
index. Specifically, after fetching all_comments, create a dictionary where keys
are post_id values and values are lists of comments belonging to that post, then
in the for loop that processes posts, assign post["comments"] by looking up the
post["id"] in the index dictionary instead of filtering through all_comments
each time.
In `@frontend/src/pages/community.tsx`:
- Line 40: The fetchFeed() function calls at lines 40 and 53 are not being
awaited, which means any errors during feed refresh will not be caught by the
surrounding try/catch blocks and can result in unhandled promise rejections. Add
the await keyword before both fetchFeed() calls to ensure they complete and any
errors are properly caught by the try/catch blocks that wrap these operations.
- Around line 107-109: The empty-state message in the conditional rendering
block is displaying even when an error exists, causing both error and
empty-state messages to appear simultaneously. Add an !error check to the
existing condition that currently checks !loading && posts.length === 0 so that
the empty-state message only renders when there is no error present, ensuring a
consistent and non-conflicting state representation.
In `@frontend/src/utils/communityApi.ts`:
- Around line 17-20: The JSON.parse call when parsing the localStorage value in
communityApi.ts can throw an exception if the stored data is malformed or stale,
causing all API calls to fail. Wrap the entire localStorage retrieval and
JSON.parse logic in a try/catch block, and when an error is caught or the
parsing fails, fall back to using unauthenticated headers instead of breaking
the API call flow. This ensures the function continues to work even when the
cached session data is invalid.
- Around line 2-3: Replace the invalid window.process pattern with direct access
to the Next.js environment variable. Remove the globalEnv variable and the
window check, then change the BASE_URL assignment to use
process.env.NEXT_PUBLIC_API_BASE_URL directly (note the correct name is
NEXT_PUBLIC_API_BASE_URL, not NEXT_PUBLIC_API_URL as currently referenced). Keep
the fallback to 'http://localhost:8000' if the environment variable is
undefined. This aligns with the idiomatic Next.js pattern used in farmApi.ts and
supabase.ts where NEXT_PUBLIC_ prefixed variables are safely accessed directly
in client code.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: a42be421-d478-4b51-8c1d-cce935e66c7f
⛔ Files ignored due to path filters (1)
frontend/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
backend/main.pybackend/supabase/migrations/20260620000000_community_feed.sqlfrontend/package.jsonfrontend/src/pages/community.tsxfrontend/src/utils/communityApi.ts
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
backend/main.py (2)
834-834:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDo not expose raw exception details to API clients.
The
detail=str(e)directly returns backend error messages to clients, potentially exposing database errors, file paths, or system details. Return a generic message and log the actual error server-side instead.🔒 Proposed fix to sanitize exception exposure
except Exception as e: - raise HTTPException(status_code=500, detail=str(e)) + print(f"Error in wiki search: {str(e)}") + raise HTTPException( + status_code=500, + detail="An internal server error occurred while processing the wiki search." + ) from 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 `@backend/main.py` at line 834, The HTTPException being raised with detail=str(e) exposes raw backend error information to API clients, creating a security risk. Replace the detail parameter with a generic error message like "An internal server error occurred" and instead log the actual exception details (the variable e) using a server-side logger at the error level. This ensures sensitive system information is only visible in server logs, not exposed to clients.
78-95:⚠️ Potential issue | 🟠 MajorApply consistent exception handling to match the sanitization pattern in community endpoints.
The new community endpoints correctly use generic error messages (e.g.,
"An internal server error occurred while processing the community feed."), but theverify_tokenfunction and other endpoints still expose raw exception details. Update line 95 and the similar patterns at lines 531, 779, and 834 to sanitize error messages consistently across all endpoints.🤖 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 `@backend/main.py` around lines 78 - 95, The verify_token function currently exposes raw exception details in the error message (line 95) by including str(e) in the HTTPException detail, which is inconsistent with the sanitization pattern used in the community endpoints. Replace the dynamic error message in the verify_token function that includes str(e) with a generic error message like "An internal server error occurred" to avoid exposing implementation details. Apply the same sanitization pattern to the similar error handling blocks at lines 531, 779, and 834 by removing exception details from all HTTPException detail messages and using consistent generic error messages instead.
🧹 Nitpick comments (1)
backend/main.py (1)
877-880: ⚡ Quick winAdd exception chaining for better debugging.
Python best practice (PEP 3134) recommends using
from eto preserve the exception chain, which helps with debugging while still controlling the client-facing message.♻️ Proposed fix to add exception chaining
raise HTTPException( status_code=500, detail="An internal server error occurred while processing the community feed." - ) + ) from 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 `@backend/main.py` around lines 877 - 880, The HTTPException being raised in the community feed error handler is not preserving the original exception chain. Modify the raise HTTPException statement to include exception chaining by adding `from e` at the end of the raise statement, where `e` is the caught exception variable. This will ensure the original exception context is preserved for debugging while still returning the generic error message to the client.
🤖 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 `@backend/main.py`:
- Around line 896-901: The error log message in the exception handling block
says "Error fetching community feed" but this code is located in the
`create_community_post` endpoint, which is misleading for debugging post
creation failures. Update the print statement message to accurately reflect that
an error occurred while creating a community post instead of fetching a feed,
and modify the raise HTTPException statement to use exception chaining with
`from e` syntax to preserve the original exception context.
- Around line 916-921: The error log message in the exception handler for the
create_community_comment endpoint incorrectly states "Error fetching community
feed" which appears to be copy-pasted from another endpoint. Update the print
statement to accurately reflect the actual operation being performed (creating a
community comment rather than fetching a feed). Additionally, add exception
chaining by using the from e syntax in the raise statement to preserve the
original error context for debugging purposes.
---
Outside diff comments:
In `@backend/main.py`:
- Line 834: The HTTPException being raised with detail=str(e) exposes raw
backend error information to API clients, creating a security risk. Replace the
detail parameter with a generic error message like "An internal server error
occurred" and instead log the actual exception details (the variable e) using a
server-side logger at the error level. This ensures sensitive system information
is only visible in server logs, not exposed to clients.
- Around line 78-95: The verify_token function currently exposes raw exception
details in the error message (line 95) by including str(e) in the HTTPException
detail, which is inconsistent with the sanitization pattern used in the
community endpoints. Replace the dynamic error message in the verify_token
function that includes str(e) with a generic error message like "An internal
server error occurred" to avoid exposing implementation details. Apply the same
sanitization pattern to the similar error handling blocks at lines 531, 779, and
834 by removing exception details from all HTTPException detail messages and
using consistent generic error messages instead.
---
Nitpick comments:
In `@backend/main.py`:
- Around line 877-880: The HTTPException being raised in the community feed
error handler is not preserving the original exception chain. Modify the raise
HTTPException statement to include exception chaining by adding `from e` at the
end of the raise statement, where `e` is the caught exception variable. This
will ensure the original exception context is preserved for debugging while
still returning the generic error message to the client.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: ded54e32-9a48-4526-83e8-dc49312590ea
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
backend/main.pyfrontend/src/pages/community.tsxfrontend/src/utils/communityApi.tsrequirements.txt
🚧 Files skipped from review as they are similar to previous changes (2)
- frontend/src/pages/community.tsx
- frontend/src/utils/communityApi.ts
|
Hey, it looks like there are merge conflicts with the main branch because we recently merged some other PRs! Could you please pull the latest main into your branch, resolve the conflicts in backend/main.py and package-lock.json, and push again? |
|
@jpdevhub pls check I update pr |
|
Hey! It looks like you tried to manually resolve the merge conflict inside frontend/package-lock.json. Unfortunately, because it's a massive generated file, doing this left some stray text (feat/community-page and main) inside the file, making it invalid JSON. Because it's invalid JSON, the testing framework is crashing entirely! The easiest way to resolve a package-lock.json conflict is to just regenerate it: 1. cd frontend 2. rm package-lock.json (Delete the corrupted file) 3. npm install (This will cleanly generate a brand new lockfile without conflicts) 4. Commit the new lockfile and push! |
2 participants
Summary
Community Question and Answer Board
Related Issue
Closes #25
Changes
Here is a brief summary of the changes:
Testing
[x] Tested locally (describe steps)
1.Frontend Isolation: Navigated to the frontend directory, initialized local node modules using npm install to load correct core types, and booted up the decoupled interface server via npm run dev. Verified that the community dashboard mounts perfectly on http://localhost:3000/community with zero remaining syntax or layout errors.
2.Backend & API Mocking: Verified the data-binding layer by isolating communityApi from live database configurations. Successfully tested the page loops, nested comment arrays, and submission state transitions using local mock structural objects to ensure error handling and UI stability without requiring a running backend stack.
Checklist
.envvalues are committed#screenshots
added.
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Maintenance