fix: optimize OAS path ordering by only adding synthetic entries for conflicting paths #7966
+309
−25
probelabs / Visor: architecture
failed
Apr 6, 2026 in 34s
🚨 Check Failed
architecture check failed because fail_if condition was met.
Details
📊 Summary
- Total Issues: 2
- Error Issues: 2
🔍 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 (1)
- ❌ gateway/api_definition.go:1523 - The logic for compiling OAS middleware path specifications, including the new two-pass algorithm to create "shield" entries for conflicting static paths, is almost entirely duplicated between
compileOASValidateRequestPathSpec(starting at line 1415) andcompileOASMockResponsePathSpec(starting at line 1523). This violates the DRY (Don't Repeat Yourself) principle, increases the maintenance burden, and makes the code harder to reason about. Any future bug fixes or enhancements to this complex logic would need to be applied in two separate places, increasing the risk of inconsistency.
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 1629 in gateway/api_definition.go
probelabs / Visor: architecture
architecture Issue
The logic for compiling OAS middleware path specifications, including the new two-pass algorithm to create "shield" entries for conflicting static paths, is almost entirely duplicated between `compileOASValidateRequestPathSpec` (starting at line 1415) and `compileOASMockResponsePathSpec` (starting at line 1523). This violates the DRY (Don't Repeat Yourself) principle, increases the maintenance burden, and makes the code harder to reason about. Any future bug fixes or enhancements to this complex logic would need to be applied in two separate places, increasing the risk of inconsistency.
Raw output
Refactor the common logic into a single, generic private method. This new method could accept function arguments to handle the specific differences between middleware types, such as the function to check if a specific middleware is enabled (e.g., `ValidateRequest` vs. `MockResponse`) and the function to create the appropriate `URLSpec` struct. The existing `compileOASValidateRequestPathSpec` and `compileOASMockResponsePathSpec` functions would then become thin, clear wrappers calling this new generalized function.
Loading