fix(parameters): avoid panic on double-slash request paths

[SAY-5]

Fixes #274.

Request paths containing a leading double slash (e.g. //test/path/x) make strings.Split produce an extra empty segment, so submittedSegments ends up longer than pathSegments. The loop then indexes submittedSegments[x] against a segment the request never actually had, the regex returns nil, and matches[1:] panics with slice bounds out of range [1:0].

The patch skips iterations where x is out of bounds for submittedSegments, and treats a nil regex match as a non-match rather than panicking. Regression test in parameters/path_parameters_test.go exercises the exact panic stack from the issue.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.64%. Comparing base (f95f219) to head (d9a349e).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #275      +/-   ##
==========================================
- Coverage   98.08%   97.64%   -0.44%     
==========================================
  Files          64       64              
  Lines        6987     7005      +18     
==========================================
- Hits         6853     6840      -13     
+ Misses        133      132       -1     
- Partials        1       33      +32     

Flag	Coverage Δ
unittests	97.64% <100.00%> (-0.44%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[daveshanley]

this avoids the panic, but it can silently accept the bad request. For //test/path/fubar against /test/path/{param}, the extra empty segment shifts indexing, so {param} is validated against "path" instead of "fubar", and ValidateHttpRequestWithPathItem returns valid=true, errs=0. This should either normalize segments consistently and validate fubar, or return a validation error; current behavior is neither.

[daveshanley]

Here is a suggestion.

submittedSegments := nonEmptyPathSegments(paths.StripRequestPath(request, v.document))
  pathSegments := nonEmptyPathSegments(pathValue)

  if len(submittedSegments) != len(pathSegments) {
        return false, []*errors.ValidationError{
                errors.PathParameterMissing(p, pathValue, request.URL.Path),
        }
  }

  for x := range pathSegments {
        var rgx *regexp.Regexp
        // existing regex cache/build code...

        matches := rgx.FindStringSubmatch(submittedSegments[x])
        if matches == nil {
                continue
        }

        matches = matches[1:]
        // existing match validation code...
  }

  Helper:

  func nonEmptyPathSegments(path string) []string {
        raw := strings.Split(path, helpers.Slash)
        segments := make([]string, 0, len(raw))

        for _, segment := range raw {
                if segment == "" {
                        continue
                }
                segments = append(segments, segment)
        }

        return segments
  }

The key is: don’t keep the original indexes after dropping/skipping empty template segments.
Either compact both sides first, or return a path/missing-param error when the segment counts
differ.

[SAY-5]

Fixed in the latest push: the approach now uses to drop empty segments from both sides before aligning them, so correctly validates against . For paths where segment counts still differ after stripping, the validator now returns a error (modeled on your suggestion). Test at line 2383 asserts the exact outcomes.

[daveshanley]

Almost there... don’t silently continue on matches == nil for a templated segment. Return a path/parameter validation error there, and update the regression test to assert invalid/no panic, not only no panic.

[SAY-5]

Reworked per your suggestion: both sides now compact empty segments via a nonEmptyPathSegments helper, and a segment-count mismatch returns PathParameterMissing instead of silently passing. The regression test now asserts the request validates fubar (valid, no errors) and that a missing-segment path is rejected.

[SAY-5]

Added a test covering the nil-match guard: TestValidatePathParamsWithPathItem_RegexNoMatchContinues uses a constrained template ({id:[0-9]+}) with a non-matching submitted value (abc), which triggers FindStringSubmatch returning nil and exercises the guard directly.

[SAY-5]

Updated: matches==nil now appends a PathParameterMissing error and breaks rather than continuing silently. Test asserts valid=false, errs non-empty.