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 98.08%. Comparing base (f95f219) to head (3c36636).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #275   +/-   ##
=======================================
  Coverage   98.08%   98.08%           
=======================================
  Files          64       64           
  Lines        6987     6999   +12     
=======================================
+ Hits         6853     6865   +12     
  Misses        133      133           
  Partials        1        1           

Flag	Coverage Δ
unittests	98.08% <100.00%> (+<0.01%)	⬆️

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]

only asserts NotPanics, so it misses the validation bypass above. The regression test should assert the returned valid/errors outcome for the issue request and the missing-segment request.

[SAY-5]

Updated the test to assert valid/errors outcomes: double-slash path returns valid=true, errs=0 (segments align after stripping); short path returns valid=false, errs=1.

[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.