Skip to content

⚡ Bolt: [performance improvement] dashboard KPIs database query optimization#114

Open
bobdivx wants to merge 1 commit into
devfrom
bolt-dashboard-kpis-optimize-4714679075040871845
Open

⚡ Bolt: [performance improvement] dashboard KPIs database query optimization#114
bobdivx wants to merge 1 commit into
devfrom
bolt-dashboard-kpis-optimize-4714679075040871845

Conversation

@bobdivx

@bobdivx bobdivx commented Jun 13, 2026

Copy link
Copy Markdown
Owner

💡 What: Refactored the /api/dashboard-kpis endpoint to replace full-table data fetches with database-level count() aggregations and filtering clauses (gte, inArray) using Drizzle ORM primitives directly via loadAstroDb().

🎯 Why: To prevent the N+1 memory bottleneck. Previously, retrieving all rows in large tables just to compute their .length or filtering them in JavaScript memory caused slow response times and excessive memory/network consumption as database size grew.

📊 Impact: Massively reduces heap memory allocations, execution time, and bandwidth utilization for the KPI dashboard query, particularly when projects have thousands of rows in AgentTask and other historical event tables.

🔬 Measurement: Observe reduction in load times/server memory spikes when hitting /api/dashboard-kpis on a database populated with thousands of AgentTask and AgentAppIssue entries. Verification via existing vitest/check scripts passes securely.


PR created automatically by Jules for task 4714679075040871845 started by @bobdivx

💡 What: Refactored the `/api/dashboard-kpis` endpoint to replace full-table data fetches with database-level `count()` aggregations and filtering clauses (`gte`, `inArray`) using Drizzle ORM primitives directly via `loadAstroDb()`.

🎯 Why: To prevent the N+1 memory bottleneck. Previously, retrieving all rows in large tables just to compute their `.length` or filtering them in JavaScript memory caused slow response times and excessive memory/network consumption as database size grew.

📊 Impact: Massively reduces heap memory allocations, execution time, and bandwidth utilization for the KPI dashboard query, particularly when projects have thousands of rows in `AgentTask` and other historical event tables.

🔬 Measurement: Observe reduction in load times/server memory spikes when hitting `/api/dashboard-kpis` on a database populated with thousands of `AgentTask` and `AgentAppIssue` entries. Verification via existing vitest/check scripts passes securely.

Co-authored-by: bobdivx <6737167+bobdivx@users.noreply.github.com>
@google-labs-jules

Copy link
Copy Markdown

👋 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.

@vercel

vercel Bot commented Jun 13, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
forge Ready Ready Preview, Comment Jun 13, 2026 5:30pm

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request optimizes the dashboard-kpis API endpoint by pushing aggregations and filtering directly to the database level using Drizzle ORM, avoiding loading entire tables into memory. It also documents this optimization in .jules/bolt.md and configures a test timeout in vitest.config.ts. The review feedback suggests restoring robust case-insensitive status filtering for AgentAppIssue and AgentDependencyRequest by utilizing Drizzle's sql helper with lower() instead of hardcoding uppercase and lowercase variants in inArray checks.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment on lines +41 to +52
const {
db,
Project,
AgentTask,
Request,
AgentAppIssue,
AgentDependencyRequest,
eq,
gte,
inArray,
count,
} = await loadAstroDb();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To support case-insensitive status filtering using sql and lower(), we need to destructure sql from loadAstroDb().

Suggested change
const {
db,
Project,
AgentTask,
Request,
AgentAppIssue,
AgentDependencyRequest,
eq,
gte,
inArray,
count,
} = await loadAstroDb();
const {
db,
Project,
AgentTask,
Request,
AgentAppIssue,
AgentDependencyRequest,
eq,
gte,
inArray,
count,
sql,
} = await loadAstroDb();

Comment on lines +78 to +96
.where(
inArray(AgentAppIssue.status, [
"open",
"in_progress",
"OPEN",
"IN_PROGRESS",
]),
),
db
.select({ value: count() })
.from(AgentDependencyRequest)
.where(
inArray(AgentDependencyRequest.status, [
"open",
"in_progress",
"OPEN",
"IN_PROGRESS",
]),
),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The previous implementation used isOpenQueueStatus which performed a case-insensitive check (.toLowerCase()). The new implementation uses inArray with a hardcoded list of uppercase and lowercase values, which will miss mixed-case statuses like "Open" or "In_progress".

To preserve the original case-insensitive behavior robustly, we can use the sql helper to lowercase the status column before performing the inArray check.

        .where(
          inArray(sql`lower(${AgentAppIssue.status})`, [
            "open",
            "in_progress",
          ]),
        ),
      db
        .select({ value: count() })
        .from(AgentDependencyRequest)
        .where(
          inArray(sql`lower(${AgentDependencyRequest.status})`, [
            "open",
            "in_progress",
          ]),
        ),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant