ProcessingMessage does not include parameter name

[Cameron]

Hey all,

I wish to use the swagger-request-validator to power my API validation, and I'm having a problem utilizing ValidationReport generated by SwaggerRequestResponseValidator#validateRequest().

If I have an API request that looks like: GET /resources?regexParams=good:val1,bad:val2 And a swagger 2.0 definition that looks like:

{
  "paths": {
    "/resources": {
      "get": {
        "parameters": [
          {
            "type": "array",
            "in": "query",
            "name": "regexParams",
            "required": true,
            "items": {
              "type": "string",
              "pattern": "^(good:).+"
            },
            "maxItems": 2
          }
        ]
      }
    }
  }
}

The ValidationReport contains 1 message as expected, but that message does not refer to the name of the parameter that caused the failure. The only bits of info in the ImmutableMessage are:

> key = "validation.schema.pattern"
> level = {ValidationReport$Level@8133}"ERROR"
> message = "ECMA 262 regex \"^(good:).+\" does not match input string \"bad:val\""
> additionalInfo = {Collections&UnmodifiableRandomAccessList@8135} size = 0

This limitation makes utilizing swagger-request-validator for API parameter validation impossible in my system - I have no way of informing the user which query parameter was problematic which is a requirement for my API.

Is there a reasonable workaround or a plan to include this as part of the validation? Thanks in advance.

[James Navin]

Interesting. If the params weren't in an array they would hit the StringParameterValidator which would nicely report the param that was failing.

Because they ARE in an array they end up hitting the ArrayParameterValidator which in turn delegates to the SchemaValidator, which comes from a 3rd party lib.

We definitely could (and should) report the array validation failure with the param name though - should be a reasonably simple change.

[Cameron]

Oh, nice! I started playing around with array validation first so I encountered it right away. I wonder if it makes sense to also include the index of the value that failed (i.e. name = "regexParams"; index = 1;) ...

I also noticed is that the "in" parameter is dropped from the validation, so it's not really possible to determine if it's a query/header/body parameter that failed (another requirement for my API validation).

Thanks for the prompt reply!

[James Navin]

I have a branch open for issue #33 which should address some of these issues (it attaches additional context to each validation message). Im hoping to have that merged in the next week.

[James Navin]

@cameronalley - additional message context has just been added in v1.4.1. Let me know if it helps you use case. Cheers.

[James Navin]

Available in v1.4.1

[Cameron]

@jfnavin That's great news! It will likely be a bit before I get a chance to revisit integration but I'll be sure to report back. Thanks a bunch for following up on this!