Tt 16809 pump generate mcp analytics #954
Merged
probelabs / Visor: architecture
failed
Apr 17, 2026 in 59s
🚨 Check Failed
architecture check failed because fail_if condition was met.
Details
📊 Summary
- Total Issues: 3
- Error Issues: 2
- Warning Issues: 1
🔍 Failure Condition Results
Failed Conditions
- global_fail_if: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')
- Severity: ❌ error
Issues by Category
Architecture (2)
- ❌ pumps/mcp_mongo.go:1 - The introduction of dedicated MCP pumps for MongoDB and SQL has resulted in significant code duplication. The new files (
mcp_mongo.go,mcp_mongo_aggregate.go,mcp_sql.go,mcp_sql_aggregate.go) are near-copies of their existing non-MCP counterparts, duplicating boilerplate logic for configuration, connection management, data batching, and writing. This approach violates the DRY principle and increases the long-term maintenance burden, as bug fixes or improvements will need to be applied in multiple places. ⚠️ analytics/aggregate_mcp.go:120 - TheAggregateMCPDatafunction duplicates the high-level structure and initialization logic found in the existingAggregateDatafunction inanalytics/aggregate.go. While the coreincrementAggregatefunction is correctly reused, the surrounding boilerplate for iterating data, managing the aggregate map, and initializing new aggregate records is repeated.
Logic (1)
- ❌ system:0 - Global failure condition met: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check failure on line 178 in pumps/mcp_mongo.go
probelabs / Visor: architecture
architecture Issue
The introduction of dedicated MCP pumps for MongoDB and SQL has resulted in significant code duplication. The new files (`mcp_mongo.go`, `mcp_mongo_aggregate.go`, `mcp_sql.go`, `mcp_sql_aggregate.go`) are near-copies of their existing non-MCP counterparts, duplicating boilerplate logic for configuration, connection management, data batching, and writing. This approach violates the DRY principle and increases the long-term maintenance burden, as bug fixes or improvements will need to be applied in multiple places.
Raw output
A more maintainable architecture would involve refactoring the common logic from the base pumps into shared components. For example, a base pump struct could handle the generic mechanics, and be configured with specific "processor" logic (e.g., a filter function and a data transformation function) for each data type (standard, GraphQL, MCP). This is inconsistent with the approach taken for the Elasticsearch pump (`pumps/elasticsearch.go`), where the new logic was integrated into the existing file rather than duplicated. A consistent architectural pattern should be applied across all pumps.
Check warning on line 142 in analytics/aggregate_mcp.go
probelabs / Visor: architecture
architecture Issue
The `AggregateMCPData` function duplicates the high-level structure and initialization logic found in the existing `AggregateData` function in `analytics/aggregate.go`. While the core `incrementAggregate` function is correctly reused, the surrounding boilerplate for iterating data, managing the aggregate map, and initializing new aggregate records is repeated.
Raw output
Refactor the common aggregation workflow into a single, generic function. This function could accept a strategy or configuration object that defines the type-specific logic, such as how to filter records, how to initialize a new aggregate struct, and how to increment type-specific dimensions. This would reduce code duplication and make the aggregation logic easier to extend in the future.
Loading