[TT-16890] Validate middleware speicifc fix #7974

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

lghiur merged 23 commits into master from TT-16890-v2

Apr 15, 2026

Merged

[TT-16890] Validate middleware speicifc fix #7974

Merge branch 'master' into TT-16890-v2

probelabs / Visor: quality succeeded Apr 15, 2026 in 1m 16s

✅ Check Passed (Warnings Found)

quality check passed. Found 4 warnings, but fail_if condition was not met.

Details

📊 Summary

Total Issues: 4
Warning Issues: 4

🔍 Failure Condition Results

Passed Conditions

global_fail_if: Condition passed

Issues by Category

Architecture (1)

⚠️ gateway/mw_oas_validate_request.go:147 - The custom path parameter validation logic in pathParamsMatchOperation, valueMatchesSchema, and valueMatchesFormat is a partial reimplementation of the validation performed by the kin-openapi library. While this is a valid performance optimization to avoid running full validation on every candidate, it introduces a maintenance risk. This custom logic must be kept in sync with kin-openapi's behavior to avoid inconsistencies and subtle bugs in the future. This trade-off should be documented clearly in the code.

Style (1)

⚠️ gateway/api_definition.go:84 - The functions mergeMockGroupIntoPrimary and mergeGroupIntoPrimary (line 120) are structurally identical, differing only in the types and field names they handle. This represents code duplication that could be reduced.

Documentation (1)

⚠️ gateway/mw_oas_validate_request_path_priority_test.go:368 - The comment in this test case describes the buggy behavior that existed before this PR's changes, which could be confusing. The test itself correctly asserts the new, fixed behavior. The comment should be updated to reflect why the test passes with the new logic.

Performance (1)

⚠️ gateway/mw_oas_validate_request.go:200 - The UUID validation regex is compiled on every request that requires this check within the valueMatchesFormat function. For performance, this regex should be compiled once at the package level using regexp.MustCompile and reused.

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>

Annotations

Check warning on line 204 in gateway/mw_oas_validate_request.go

probelabs / Visor: quality

architecture Issue

The custom path parameter validation logic in `pathParamsMatchOperation`, `valueMatchesSchema`, and `valueMatchesFormat` is a partial reimplementation of the validation performed by the `kin-openapi` library. While this is a valid performance optimization to avoid running full validation on every candidate, it introduces a maintenance risk. This custom logic must be kept in sync with `kin-openapi`'s behavior to avoid inconsistencies and subtle bugs in the future. This trade-off should be documented clearly in the code.

Raw output


            Add a comment to the `pathParamsMatchOperation` function explaining that this is a performance-optimized pre-check and that it needs to be kept in sync with the behavior of the `kin-openapi` library to ensure correctness.

Check warning on line 106 in gateway/api_definition.go

probelabs / Visor: quality

style Issue

The functions `mergeMockGroupIntoPrimary` and `mergeGroupIntoPrimary` (line 120) are structurally identical, differing only in the types and field names they handle. This represents code duplication that could be reduced.

Raw output


            Refactor the common logic into a single function. Given the constraints of Go's type system (depending on the version used), this might involve using interfaces and type switches, or if available, generics. If a refactor is deemed too complex, add a comment acknowledging the duplication and the reason for it.

Check warning on line 372 in gateway/mw_oas_validate_request_path_priority_test.go

probelabs / Visor: quality

documentation Issue

The comment in this test case describes the buggy behavior that existed before this PR's changes, which could be confusing. The test itself correctly asserts the new, fixed behavior. The comment should be updated to reflect why the test passes with the new logic.

Raw output


            Update the comment to explain the correct behavior with the fix. For example: "With restrictiveness sorting, the `type:number` candidate `{zd}` is tried first for path `/api/employees/5`. It matches the path parameter but fails full validation due to the missing `abc` header. Because the logic commits to the first matching candidate, the request fails with 422 and does not fall through to the less-restrictive `{prct}` candidate."

Check warning on line 200 in gateway/mw_oas_validate_request.go

probelabs / Visor: quality

performance Issue

The UUID validation regex is compiled on every request that requires this check within the `valueMatchesFormat` function. For performance, this regex should be compiled once at the package level using `regexp.MustCompile` and reused.

Raw output


            Define the compiled regex at the package level:
```go
var uuidRegex = tykregexp.MustCompile(`^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$`)
```
Then, in `valueMatchesFormat`, use the compiled regex:
```go
case "uuid":
    return uuidRegex.MatchString(value)
```

View more details on probelabs