Eliminate N+1 query in getOrgChangeDetections - #195
Open
clickmatos wants to merge 1 commit into
Open
Conversation
Detecting metric changes across an org's repos issued one `metrics` query per repo, sequentially — a round-trip count that scales linearly with repo count and can stall the ChangeAlertPanel's stream on large orgs. Extends the repo_metric_summaries view (023) with the previous run's values for the metrics detectChanges compares, so the DB does the per-repo "latest vs previous" aggregation once instead of the app looping N times. getOrgChangeDetections now reads that plus the repo list — 2 bulk queries total regardless of repo count — mirroring the same fix getOrgReposSummary already applies against this view (022). Needs the migration applied to the actual Supabase project (`supabase db push` or via the dashboard) before this takes effect — not run from here. Co-Authored-By: claude-code_2-1-238_agent <claude-code_2-1-238_agent@iris.invalid>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Part of #180 (dashboard slow to load). PR #182 already fixed the bulk of it (per-section Suspense streaming, request-scoped
cache()dedup) — this fixes a concrete remaining bottleneck found while verifying that fix held up:getOrgChangeDetections(feedsChangeAlertPanel) issued onemetricsquery per repo in a sequential loop, an N+1 that scales linearly with repo count and can stall that panel's stream on large orgs.Extends the
repo_metric_summariesview (already used bygetOrgReposSummaryfor the same "N+1 → 2 bulk queries" fix) with the previous run's values for the metricsdetectChangesactually compares (revert_rate,churn_events,ai_detection_coverage_pct, plus aprev_created_attimestamp) — it already hadprev_stabilization_ratiofor the sparkline delta arrow.getOrgChangeDetectionsnow reads repos + this one pre-aggregated view, 2 queries total regardless of repo count, instead of1 + N.Filed #194 for the broader, structural gap this surfaced: there's no caching layer anywhere in the dashboard's data path —
repo_metric_summariesis a plain (non-materialized) view recomputed from scratch on every single page load, and nounstable_cache/revalidatewraps any loader. Left out of this PR since it's an architectural decision (materialized view vs. Next.js revalidation) worth its own discussion, not a drop-in fix.Test plan
npx tsc --noEmit— cleannpx eslint lib/queries/temporal.ts— cleannpx vitest run— 269 passed (detect-changes.test.tscoversdetectChangesitself, untouched by this change;getOrgChangeDetectionshas no unit tests today, consistent with this codebase's convention of integration-testing the query layer against a real DB)023_repo_metric_summaries_prev_values.sqlneedssupabase db push(or applying via the dashboard) against the actual project beforegetOrgChangeDetectionswill return real data — until then the new columns don't exist andprev_revert_rate/prev_churn_events/prev_ai_detection_coverage_pct/prev_created_atwill read asundefined. Please confirm the migration is applied as part of merging/deploying this.🤖 Generated with Claude Code