fix(backend): resolve memory leak and db pagination in catalog API - #195
Conversation
Refactored the /objects endpoint to query the SpaceObject schema directly, enabling SQL-level pagination and resolving the missing integer division bug in page calculations.
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Review limit reached
Next review available in: 43 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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 Plus Run ID: 📒 Files selected for processing (1)
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 |
| @router.get("/objects", response_model=APIResponse[List[Dict[str, Any]]]) | ||
| def _serialize_space_object(obj: SpaceObject) -> Dict[str, Any]: |
There was a problem hiding this comment.
Suggestion: The serializer is incorrectly registered as a second GET /objects route. Because this route is declared before list_space_objects, requests to /api/v1/catalog/objects match _serialize_space_object first; obj is treated as a request parameter rather than a database dependency, so the listing endpoint returns validation errors or the application can fail during FastAPI route initialization. Remove the route decorator from this helper and leave only list_space_objects registered for this path. [api mismatch]
Severity Level: Critical 🚨
- ❌ Catalog application startup or `/objects` requests fail.
- ❌ Frontend catalog data cannot load from `/api/v1/catalog/objects`.
- ⚠️ Pagination and classification filters become unreachable.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** backend/api/v1/endpoints/catalog.py
**Line:** 117:118
**Comment:**
*Api Mismatch: The serializer is incorrectly registered as a second GET `/objects` route. Because this route is declared before `list_space_objects`, requests to `/api/v1/catalog/objects` match `_serialize_space_object` first; `obj` is treated as a request parameter rather than a database dependency, so the listing endpoint returns validation errors or the application can fail during FastAPI route initialization. Remove the route decorator from this helper and leave only `list_space_objects` registered for this path.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| # FIX: Query the unified SpaceObject schema to enable DB-level pagination | ||
| query = db.query(SpaceObject) |
There was a problem hiding this comment.
Suggestion: The endpoint now counts and retrieves only rows from SpaceObject, but the Space-Track synchronization code upserts records exclusively into Satellite or Debris. Newly synchronized catalog records, and existing records present only in those tables, therefore do not appear in this endpoint and are omitted from total and pagination. Either populate SpaceObject as part of synchronization or query the source tables consistently. [incomplete implementation]
Severity Level: Critical 🚨
- ❌ Synchronized satellites disappear from catalog listings.
- ❌ Synchronized debris are omitted from totals.
- ⚠️ Classification filters and pagination metadata become incomplete.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** backend/api/v1/endpoints/catalog.py
**Line:** 157:158
**Comment:**
*Incomplete Implementation: The endpoint now counts and retrieves only rows from `SpaceObject`, but the Space-Track synchronization code upserts records exclusively into `Satellite` or `Debris`. Newly synchronized catalog records, and existing records present only in those tables, therefore do not appear in this endpoint and are omitted from `total` and pagination. Either populate `SpaceObject` as part of synchronization or query the source tables consistently.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| # FIX: Correct the pagination math | ||
| pages = (total + size - 1) // size |
There was a problem hiding this comment.
Suggestion: For an empty filtered catalog, this formula produces pages=0, while the other paginated catalog APIs return one page for an empty result set. Clients using the shared pagination contract can therefore receive an inconsistent or invalid page count when no objects match. Preserve the empty-result behavior by returning one page when total is zero. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ Empty catalog filters return inconsistent page metadata.
- ⚠️ Clients may treat zero pages as invalid pagination.
- ⚠️ Catalog behavior differs from other paginated APIs.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** backend/api/v1/endpoints/catalog.py
**Line:** 171:172
**Comment:**
*Api Mismatch: For an empty filtered catalog, this formula produces `pages=0`, while the other paginated catalog APIs return one page for an empty result set. Clients using the shared pagination contract can therefore receive an inconsistent or invalid page count when no objects match. Preserve the empty-result behavior by returning one page when `total` is zero.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
User description
Summary
This PR addresses severe performance and logic bugs in the CAPI backend related to database schema queries. The
/api/v1/catalog/objectsendpoint previously queriedSatelliteandDebrisseparately, loading the entire database table into memory (.all()) before manually slicing the array in Python. It also had a syntax bug calculating the total pages (pages = (total + size - 1)missing the// sizeoperator).This update refactors the endpoint to query the unified
SpaceObjectschema, enabling.offset()and.limit()pagination at the database level, preventing memory exhaustion and fixing the pagination metadata.Related Issue
Closes #193
Type of Change
Screenshots / Screen Recordings
No essential SS required
Testing Performed
/objectsendpoint correctly paginates and filters by classification)Breaking Changes
None. The API response schema remains perfectly intact.
Checklist
ECSoC26 Submission
ECSoC26-L1– BeginnerECSoC26-L2– IntermediateECSoC26-L3– AdvancedCodeAnt-AI Description
Fix catalog pagination and reduce memory use for large object lists
What Changed
Impact
✅ Lower memory use for large catalog requests✅ Correct page counts and result totals✅ Faster catalog responses for paginated queries💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.