⚡ Bolt: scope user lesson progress database queries - #90
Conversation
…nt lessons
Avoid fetching the student's entire lesson progress history in the courses catalog, student dashboard, and certificate pages. Restrict queries using `lessonId: { in: allLessonIds }` where `allLessonIds` matches only the lessons rendered on the specific page. This prevents redundant database records, reduces memory footprint, and improves response latency.
Co-authored-by: projectamazonph <286085559+projectamazonph@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
📝 WalkthroughWalkthroughDashboard, course index, and certificate pages now filter ChangesLesson progress query scoping
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. 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: 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 @.jules/bolt.md:
- Around line 7-9: Rewrite the journal entry’s Learning and Action text in plain
language: explain that unscoped queries load unused records, use more memory,
and can slow the page. Replace technical terms such as “payloads” and “query
latency” with direct wording while preserving the guidance to filter progress by
the relevant lessonIds.
🪄 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: 94916e55-de82-465f-9deb-b1b6bbddcf53
📒 Files selected for processing (4)
.jules/bolt.mdsrc/app/(dashboard)/courses/[courseSlug]/certificate/page.tsxsrc/app/(dashboard)/courses/page.tsxsrc/app/(dashboard)/dashboard/page.tsx
| ## 2026-07-17 - [Querying Unscoped User Lesson Progress History] | ||
| **Learning:** Querying a user's entire `lessonProgress` history without scoping to relevant courses or specific lesson IDs fetches redundant records from the database, resulting in unnecessary payloads, high memory consumption, and increased query latency as the student progresses. | ||
| **Action:** Extract the specific `lessonIds` of interest (e.g. from current courses/modules being rendered) and filter the progress lookup with `lessonId: { in: lessonIds }`. Avoid fetching the entire table by always scoping user-specific queries. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use plain language for the journal entry.
“Payloads” and “query latency” are unexplained jargon. State that the query loads unused records, consumes more memory, and can slow the page.
Suggested wording
-**Learning:** Querying a user's entire `lessonProgress` history without scoping to relevant courses or specific lesson IDs fetches redundant records from the database, resulting in unnecessary payloads, high memory consumption, and increased query latency as the student progresses.
-**Action:** Extract the specific `lessonIds` of interest (e.g. from current courses/modules being rendered) and filter the progress lookup with `lessonId: { in: lessonIds }`. Avoid fetching the entire table by always scoping user-specific queries.
+**Learning:** Querying a user's entire `lessonProgress` history loads records the page does not use. This uses more server memory and can make the page slower as the student completes more lessons.
+**Action:** Get the lesson IDs shown on the page and filter the progress lookup with `lessonId: { in: lessonIds }`. This loads only the progress records the page needs.As per coding guidelines, define jargon and use direct, plain-spoken language for the Filipino VA audience.
📝 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.
| ## 2026-07-17 - [Querying Unscoped User Lesson Progress History] | |
| **Learning:** Querying a user's entire `lessonProgress` history without scoping to relevant courses or specific lesson IDs fetches redundant records from the database, resulting in unnecessary payloads, high memory consumption, and increased query latency as the student progresses. | |
| **Action:** Extract the specific `lessonIds` of interest (e.g. from current courses/modules being rendered) and filter the progress lookup with `lessonId: { in: lessonIds }`. Avoid fetching the entire table by always scoping user-specific queries. | |
| ## 2026-07-17 - [Querying Unscoped User Lesson Progress History] | |
| **Learning:** Querying a user's entire `lessonProgress` history loads records the page does not use. This uses more server memory and can make the page slower as the student completes more lessons. | |
| **Action:** Get the lesson IDs shown on the page and filter the progress lookup with `lessonId: { in: lessonIds }`. This loads only the progress records the page needs. |
🤖 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 @.jules/bolt.md around lines 7 - 9, Rewrite the journal entry’s Learning and
Action text in plain language: explain that unscoped queries load unused
records, use more memory, and can slow the page. Replace technical terms such as
“payloads” and “query latency” with direct wording while preserving the guidance
to filter progress by the relevant lessonIds.
Source: Coding guidelines
💡 What:
Scoped the
db.lessonProgress.findManydatabase queries in the main courses list (src/app/(dashboard)/courses/page.tsx), the student dashboard (src/app/(dashboard)/dashboard/page.tsx), and the pending lessons list on the certificate page (src/app/(dashboard)/courses/[courseSlug]/certificate/page.tsx).🎯 Why:
Previously, these pages fetched the user's entire
lessonProgresshistory from the database, which leads to large database payloads, high memory consumption, and increased query latency as students complete more courses over time.📊 Impact:
Significantly reduces query payload and memory usage by retrieving only the
lessonProgressrecords matching the lessons rendered on the current page, ensuring O(N) database scaling relative to the active view rather than O(Total student progress history).🔬 Measurement:
Run
pnpm testandpnpm buildto verify correctness. Verify that the querydb.lessonProgress.findManyis scoped withlessonId: { in: allLessonIds }in all three modified locations.PR created automatically by Jules for task 836231224308898883 started by @projectamazonph
Summary by CodeRabbit