[TT-12238] Javascript regex issue on OAS API #7923
Merged
probelabs / Visor: performance
succeeded
Apr 16, 2026 in 49s
✅ 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.go:1282 - Cloning and processing a large OAS object on every GET request can be inefficient. TheapiOAS.Clone()operation followed byvisitor.ProcessOAS()introduces CPU and memory overhead for each call to this endpoint. For large and complex OAS definitions, this can lead to increased latency and garbage collection pressure under load.⚠️ gateway/api.go:3698 - The function re-marshals the modified OAS object intoreqBodyInBytes, but this return value appears to be unused by its callers (handleAddApiandhandleUpdateAPI). This results in unnecessary CPU and memory allocation for a serialization operation whose result is immediately discarded.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check warning on line 1282 in gateway/api.go
probelabs / Visor: performance
performance Issue
Cloning and processing a large OAS object on every GET request can be inefficient. The `apiOAS.Clone()` operation followed by `visitor.ProcessOAS()` introduces CPU and memory overhead for each call to this endpoint. For large and complex OAS definitions, this can lead to increased latency and garbage collection pressure under load.
Raw output
Consider caching the processed, public-facing OAS definition. When an API is loaded or updated, you could generate and cache both the internal representation and the public representation (with Tyk extensions removed and regexes restored). This would trade a small amount of memory for a significant performance gain on this read-heavy endpoint, turning the expensive computation into a simple cache lookup.
Check warning on line 3698 in gateway/api.go
probelabs / Visor: performance
performance Issue
The function re-marshals the modified OAS object into `reqBodyInBytes`, but this return value appears to be unused by its callers (`handleAddApi` and `handleUpdateAPI`). This results in unnecessary CPU and memory allocation for a serialization operation whose result is immediately discarded.
Raw output
Verify the usage of the returned `reqBodyInBytes` in the calling functions. If it is indeed unused, remove the `json.Marshal` call and the related error handling. The function signature can be updated to no longer return the `[]byte` slice.
Loading