fix: optimize OAS path ordering by only adding synthetic entries for conflicting paths #7966
probelabs / Visor: performance
succeeded
Apr 6, 2026 in 32s
✅ Check Passed (Warnings Found)
performance check passed. Found 2 warnings, but fail_if condition was not met.
Details
📊 Summary
- Total Issues: 2
- Warning Issues: 2
🔍 Failure Condition Results
Passed Conditions
- global_fail_if: Condition passed
Issues by Category
Performance (2)
⚠️ gateway/api_definition.go:1491 - The logic to find conflicting static paths introduces a nested loop that could lead to poor performance during API load time for very large OpenAPI specifications. For each static path, the code iterates through all parameterized paths that have middleware enabled, performing a regex match. This results in an algorithmic complexity of O(S * M), where S is the number of static paths and M is the number of parameterized paths. For an API with thousands of static paths and hundreds of parameterized paths, this could introduce a noticeable delay in API loading or reloading.⚠️ gateway/api_definition.go:1617 - This section duplicates the O(S * M) algorithmic complexity issue found incompileOASValidateRequestPathSpec. For each static path, it iterates through all parameterized paths with mock responses enabled to check for conflicts via regex matching. This can significantly slow down API load times for specifications with a large number of paths.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check warning on line 1496 in gateway/api_definition.go
probelabs / Visor: performance
performance Issue
The logic to find conflicting static paths introduces a nested loop that could lead to poor performance during API load time for very large OpenAPI specifications. For each static path, the code iterates through all parameterized paths that have middleware enabled, performing a regex match. This results in an algorithmic complexity of O(S * M), where S is the number of static paths and M is the number of parameterized paths. For an API with thousands of static paths and hundreds of parameterized paths, this could introduce a noticeable delay in API loading or reloading.
Raw output
For APIs with a very large number of paths, consider optimizing the conflict detection mechanism. Instead of a linear scan of all parameterized regexes for each static path, a more efficient data structure could be used. For example, the static prefixes of parameterized paths could be compiled into a single optimized regex or a prefix tree (trie) to allow for faster lookups. However, for the majority of use cases, the current implementation's trade-off of slower load time for faster request time is reasonable.
Check warning on line 1622 in gateway/api_definition.go
probelabs / Visor: performance
performance Issue
This section duplicates the O(S * M) algorithmic complexity issue found in `compileOASValidateRequestPathSpec`. For each static path, it iterates through all parameterized paths with mock responses enabled to check for conflicts via regex matching. This can significantly slow down API load times for specifications with a large number of paths.
Raw output
The suggestion is the same as for the `compileOASValidateRequestPathSpec` function. Consider a more optimized data structure for conflict detection, such as a combined regex or a prefix tree, if load times for very large APIs become a concern.
Loading