Skip to content

⚡ Bolt: Optimize checkAchievements database operations - #113

Draft
google-labs-jules[bot] wants to merge 1 commit into
mainfrom
bolt/gamification-performance-optimization-3281644593256344958
Draft

⚡ Bolt: Optimize checkAchievements database operations#113
google-labs-jules[bot] wants to merge 1 commit into
mainfrom
bolt/gamification-performance-optimization-3281644593256344958

Conversation

@google-labs-jules

Copy link
Copy Markdown
Contributor

⚡ Bolt Optimization: checkAchievements

💡 What:
Optimized the checkAchievements function in gamificationController.js.
Instead of executing database inserts and user updates sequentially inside the achievement loop, I:

  1. Accumulated the total XP reward.
  2. Collected all insert promises (user_achievements, notifications, tracking).
  3. Executed all inserts concurrently using Promise.all.
  4. Called User.addXP once with the total accumulated XP.

🎯 Why:
The original implementation suffered from an N+1 query problem (actually N*4) when multiple achievements were unlocked simultaneously. Each achievement triggered 3 separate DB writes plus 1 read/write for user update.
For 3 achievements, this meant ~12 sequential DB operations.
The new implementation reduces this to ~2 sequential steps (Batch Inserts + 1 User Update).

📊 Impact:

  • Reduces users table updates from N to 1.
  • Parallelizes N inserts for auxiliary tables.
  • Significantly reduces latency for users unlocking multiple achievements (e.g., leveling up or completing complex quests).

🔬 Measurement:
Added backend/tests/gamificationPerformance.test.js which verifies that User.addXP is called exactly once with the total XP amount, confirming the optimization.


PR created automatically by Jules for task 3281644593256344958 started by @4444J99

- Batch DB inserts for user_achievements, notifications, and events using Promise.all
- Accumulate XP rewards and call User.addXP once instead of N times
- Fixes N+1 query issue in achievement unlocking loop
- Adds verification test backend/tests/gamificationPerformance.test.js
@google-labs-jules

Copy link
Copy Markdown
Contributor Author

👋 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 @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@coderabbitai

coderabbitai Bot commented Jan 19, 2026

Copy link
Copy Markdown

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Comment @coderabbitai help to get the list of available commands and usage tips.

@4444J99

4444J99 commented Jul 19, 2026

Copy link
Copy Markdown
Member

Engaging as a real, still-open perf want (not falsely marked done): I confirmed the N+1 on current maingamificationController.checkAchievements loops over unlocked achievements and runs 3 sequential awaits per achievement (INSERT user_achievements, user.addXPuser.save, INSERT notifications, around lines 133–173). The safe distilled form is to aggregate XP into a single addXP and bulk-insert the achievement + notification rows once. I'm not blind-merging this stale/conflicting draft because a DB-write refactor needs a live-DB integration test to verify correctness (achievement unlocking must not regress). Keeping this open as the anchor for that verified distillation — never closed.

@4444J99 4444J99 added the lifecycle:blocked Fail-closed pending explicit lifecycle review label Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

lifecycle:blocked Fail-closed pending explicit lifecycle review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant