fix(builder): purge function_complexity on full rebuild

[carlos-alm]

Summary

• Fixes fix(ci): use commit-count versioning for dev builds and benchmarks #173 — --no-incremental full rebuilds now clear the function_complexity table before inserting new data
• Without this fix, old complexity rows became orphaned on each full rebuild (node IDs are reassigned), causing unbounded table growth (2160→2879→3599 rows observed across 3 rebuilds, while only ~720 are valid)
• One-line addition of DELETE FROM function_complexity; to the full-rebuild purge sequence in builder.js

Test plan

• npm test — all integration/unit tests pass (no regressions)
• npm run lint — clean
• Manual: node src/cli.js build . --no-incremental twice, verify SELECT COUNT(*) FROM function_complexity stays constant

[claude]

Claude finished @carlos-alm's task —— View job

---

PR Review - Analysis Complete

Reviewing PR #239: fix(builder): purge function_complexity on full rebuild

Todo List:

• Phase 1: Root cause analysis - understand the problem and solution approach
• Phase 2: Configuration change detection - check for high-risk changes
• Phase 3: Test integrity - look for red flags in testing approach
• Phase 4: Code quality review - analyze implementation details
• Final Assessment: Provide rating and recommendation

Phase 1 Analysis ✅

Problem Being Solved: During --no-incremental full rebuilds, the function_complexity table is not purged before new data is inserted. Since node IDs are reassigned on full rebuilds, old complexity rows become orphaned and accumulate indefinitely, causing unbounded table growth.

Evidence: Author reports table growth from 2160→2879→3599 rows across 3 rebuilds while only ~720 should be valid.

Solution Approach: Add DELETE FROM function_complexity; to the existing purge sequence on line 438 in builder.js.

Phase 2 Analysis ✅

Configuration Changes: ✅ NONE - No configuration, linting, test thresholds, or build settings modified.

Phase 3 Analysis ✅

Test Integrity: ✅ GOOD

• No test expectations lowered or assertions weakened
• Author claims tests pass (npm test, npm run lint)
• Manual test plan provided for verification
• Existing tests should continue to pass as the change only affects full rebuild cleanup

Phase 4 Analysis ✅

Code Quality: ✅ EXCELLENT

• Perfect consistency: Incremental builds already clean up function_complexity per-file via deleteComplexityForFile?.run(relPath) (lines 512, 520). This PR simply ensures full rebuilds do the same globally.
• Foreign key safety: Correctly placed in deletion sequence before DELETE FROM nodes since function_complexity.node_id has a foreign key constraint to nodes.id.
• Minimal risk: One-line addition to existing proven purge pattern used for node_metrics and edges.
• Schema alignment: function_complexity table exists since migration v8 (lines 116-125 in db.js) with proper foreign key constraints.
• Error handling: Uses same try/catch pattern as incremental builds for missing table scenarios.

Technical Verification:

• ✅ Change is in correct location (full rebuild purge sequence at line 438)
• ✅ Maintains deletion order: node_metrics → edges → function_complexity → nodes
• ✅ Consistent with incremental cleanup pattern already implemented
• ✅ No performance impact (full rebuilds already do multiple table deletions)

Root Cause Analysis

Problem Being Solved: Legitimate data consistency bug - orphaned complexity rows accumulate on full rebuilds due to node ID reassignment.

Why This Approach: Correctly follows existing architectural pattern. Incremental builds already handle this per-file; full builds simply needed the same global cleanup.

Risk Assessment: MINIMAL - Single line addition to proven deletion pattern, maintains referential integrity order.

Critical Concerns

None. This is a clean, minimal fix addressing a real data consistency issue.

Final Recommendation

• Rating: ⭐⭐⭐⭐⭐ (5/5)
• Action: APPROVE - Excellent fix with perfect execution
• Reasoning: Fixes legitimate bug with minimal, well-placed change that follows existing patterns. Change is technically sound, properly positioned, and maintains referential integrity. Author provided clear evidence of the problem and appropriate testing approach.

---

[greptile-apps]

Greptile Summary

Fixes unbounded function_complexity table growth during full rebuilds by adding DELETE FROM function_complexity; to the purge sequence in buildGraph().

Changes:

• Added single deletion statement to the full-rebuild purge sequence (line 438)
• Placed correctly between DELETE FROM edges; and DELETE FROM nodes; to maintain proper deletion order for foreign key constraints
• Follows existing pattern for other child tables (node_metrics, edges, embeddings)

Why this was needed:
When --no-incremental full rebuilds run, all nodes are deleted and recreated with new auto-incremented IDs. Without purging function_complexity, old rows become orphaned (referencing deleted node IDs), causing unbounded growth (2160→2879→3599 rows observed across rebuilds when only ~720 are valid).

Safety:
The fix is safe because:

• Foreign keys are temporarily disabled during the deletion sequence
• Complexity data is recomputed and reinserted after rebuild using INSERT OR REPLACE pattern
• No data loss—complexity metrics are recalculated from source code during each build
• Consistent with how node_metrics, edges, and embeddings are already handled

Confidence Score: 5/5

• This PR is safe to merge with no risk
• Single-line fix that correctly addresses a well-documented bug by adding the missing table deletion to match the existing pattern for other foreign-key-constrained tables. The change is minimal, follows established conventions, and has no side effects.
• No files require special attention

Important Files Changed

Filename	Overview
src/builder.js	Added DELETE FROM function_complexity; to full-rebuild purge sequence to prevent orphaned rows and unbounded table growth

_{Last reviewed commit: 453e81a}

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}