Data Race when handling simultaneously requests

[wrong-user]

I am facing an Data Race when I am sending simultaneously request against my service that is using

kin-openapi/openapi3filter/validate_request.go

Line 32 in e53fe38

func ValidateRequest(ctx context.Context, input *RequestValidationInput) (err error) {

to validate the incoming requests.

The OpenApi specification is loaded by the service. Validation of the request against the spec is handle in a middleware before it is handle by the service itself, or reject if it does not adhere to the spec.

The race is occurring because of a write at

kin-openapi/openapi3/schema.go

Line 1973 in e53fe38

if schema.compiledPattern, err = regexp.Compile(schema.Pattern); err != nil {

and a read at

kin-openapi/openapi3/schema.go

Line 1608 in e53fe38

if cp := schema.compiledPattern; cp != nil && !cp.MatchString(value) {

Out of curiosity I added a mutex in the schema struct and applied it in as below.

// Schema.go:1599
schema.PatternMu.Lock()
if schema.Pattern != "" && schema.compiledPattern == nil && !settings.patternValidationDisabled {
  var err error
  if err = schema.compilePattern(); err != nil {
    if !settings.multiError {
      return err
    }
    me = append(me, err)
  }
}
schema.PatternMu.Unlock()

I am running it with v.0.114.0 at commit ecb06bc, but the issue is also present in older versions.

[fenollp]

Hello please show us: open a PR with a test that reproduces your issue. Thanks.

[wrong-user]

Sure, I will do that.

[fenollp]

Hey so I have a fix, two actually!

Short term: doc.Validate(ctx) before building your router. You should do that anyway. It pre compiles all patterns so in effect fixes this issue.

Longer term: I'll propose a patch that relies on a package-global sync.Map.

But do validate your docs!