Skip to content

fix: use custom sorting for OAS middleware compilation to fix prefix …

f3ca8f9
Select commit
Loading
Failed to load commit list.
Open

fix: optimize OAS path ordering by only adding synthetic entries for conflicting paths #7966

fix: use custom sorting for OAS middleware compilation to fix prefix …
f3ca8f9
Select commit
Loading
Failed to load commit list.
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) 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.

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

See this annotation in the file changed.

@probelabs 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.