Handle example keyword validation #472

lag-of-death · 2019-08-21T12:08:40Z

Fixes #223 .

Checklist

Tests added / updated
Docs added / updated

Does this PR introduce a breaking change?

Yes
No

Additional context

TL;DR

This PR adds all that is needed to validate example against its schema in both OAS2 and OAS3. Validation of examples is not handled. Also validation of example against encoding (OAS3) is also not handled.

Findings:

I have not found a need for separate rules for example(s) in different places (like in a header, in body etc). The added rule and the adjusted one handle example validation against its schema. But, OAS3 talks about validating example(s) against its encoding. This is vary vague. Encoding, it seems, is defined in Encoding Object and Encoding Object is only to be found in Media Type Object (so in Response/Request Object(s)). This might need further investigation and maybe should be handled later (not in this PR).

If we are to validate examples, then there is a possible need for additional rules. Couldn't work out anything to validate examples with the current rules and json-path-plus magic.

OAS2

`example` keyword

The only place that allows example keyword is inside of Schema Object. Schema Object also allows required keyword. But this required keyword is an array, so we have no problem with

spectral/src/functions/schema.ts

Line 36 in 4307a0c

validator = ajv.compile(schemaObj);

because the required attribute will never be a boolean. It will always be an array (just because it is Schema Object, which is a set of JSON Schema.

Required attribute is also found in Parameter Object, but Parameter Object does not allow an example keyword. So there is no conflict there.

So, it seems to me, that the greed of

spectral/src/rulesets/oas2/index.json

Line 98 in 027664f

"given": "$..[?(@.example)]",

does not pose a problem and it's OK to leave it as is.

Links:

parameter object: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#fixed-fields-7
schema object: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schema-object

`examples` keyword

To be found only in Response Object.

The name of the property MUST be one of the Operation produces values (either implicit or inherited).
The value SHOULD be an example of what such a response would look like.

from: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#example-object

I couldn't find a way to validate examples in any way with the existing rules.

A spec

I'm attaching an OAS2 example with some comments to further clarify, that there is no issue with the existing OAS2 rule:

swagger: "2.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  description: Swagger Petstore
  license:
    name: MIT
  contact:
    name: Test
paths:
  /pets/{petId}:
    get:
      summary: Info for a specific pet
      operationId: showPetById
      description: Get a pet
      tags:
        - pets
      parameters: # .example in any kind of parameter (any kind of in:) is not allowed
        - name: petId
          in: path
          type: integer
          required: true  # required is is allowed (and it is a boolean), but there never is an example alongside it
        - name: petSomething
          in: body
          required: true
          schema: # every schema is based on JSON Schema Specification Draft 4, which allows required (but as an array, so OK)
            type: object
            properties:
              abc:
                required: # required is allowed here, but only as an array
                  - age
                type: object
                example: 123
                properties:
                  age:
                    type: number
            example:
              abc: 888
      responses:
        '200':
          description: Expected response to a valid request
          examples:
            application/json: { "id": 38, "title": "T-shirt" }
              text/csv: >
                id,title
                38,T-shirt
definitions:
  Abc: # Scheme Object, no boolean required field allowed
    type: object
    properties:
      id:
        type: integer
        format: int64
        example:
          23233
      name:
        type: string
    required:
      - name
    example:
      name: Puma
      id: 1

OAS3

`example` key to be found in:

Parameter Object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#fixed-fields-10

The example SHOULD match the specified schema and encoding properties if present.

Not sure about "encoding properties" ?

Schema Object: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schema-object

A free-form property to include an example of an instance for this schema.

Media Type Object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#fixed-fields-12

Each media type includes a schema, defining the data type of the message body, and, optionally, one or several examples.

from: https://swagger.io/docs/specification/media-types/

Header Object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#header-object

The Header Object follows the structure of the Parameter Object with the following changes (...)

`required` key to be found in:

Request Body Object: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#request-body-object
schema Object: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schema-object
Parameter Object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#fixed-fields-10
Header Object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#header-object

the conflict

Parameter object (and header object), where required field is a Boolean and example is allowed. This PR solves this.

parameters:
    skipParam:
      name: skip
      in: query
      description: number of items to skip
      required: true  # boolean required and example both inside Parameter Object
      example: 34 # boolean required and example both inside Parameter Object
      schema:
        type: integer
        example: 34
        required: []
        format: int32

`examples` keyword

All examples are built with Example Object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#example-object

"In all cases, the example value is expected to be compatible with the type schema of its associated value. "

To be found in:

parameter object ( https://swagger.io/docs/specification/adding-examples/ and https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#parameter-object )
Media Type object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#media-type-object in:
a) requestBody ( https://swagger.io/docs/specification/adding-examples/ )
b) response body: ( https://swagger.io/docs/specification/adding-examples/ )

The examples in response and request bodies are free-form, but are expected to be compatible with the body schema.

components object https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#components-object

The same as with OAS2, I couldn't find a way to validate examples in any way with the existing rules (for OAS3).

lag-of-death · 2019-08-23T08:48:31Z

@philsturgeon, could you take a look if you find the time? Thanks!

philsturgeon · 2019-08-23T10:36:25Z

@lag-of-death sadly this does not solve the problem. You have added an extra conditional which does help hide the symptom of the bug, but it does not solve the feature.

We talked about different types of rules because in OAS2 and OAS3 there are various different places the example keyword can show up, and it may or may not be inside a schema. The issue you are fixing showed this valid partial OAS3 spec:

      parameters:
        - in: query
          name: petId
          required: true
          description: The id of the pet to retrieve
          schema:
            type: integer
          example: "3"

Your code will simply ignore this, and not do anything about it.

In OAS2 only some parameters have the schema keyword and some don't. Interestingly example is not a valid keyword in OAS2 but that doesn't stop a bunch of people using it anyway. In OAS2 we can either ignore it or support it, but if we support it we should support it properly, and in OAS3 we need to support example in either of its valid locations above.

lag-of-death · 2019-08-23T11:33:35Z

@philsturgeon, given this spec (that has your example included):

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  description: Swagger Petstore
  license:
    name: MIT
  contact:
    name: Test
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    get:
      summary: Info for a specific pet
      description: pets
      operationId: showPetById
      tags: [pets]
      parameters:
        - in: query
          name: petId
          required: true
          description: The id of the pet to retrieve
          schema:
            type: integer
          example: "3"
      responses:
        '200':
          description: Expected response to a valid request

I get:

Adding OpenAPI 3.x functions
Method `addRules` has been deprecated since version 4.1, use `loadRuleset` instead.
    at /snapshot/spectral/dist/cli/commands/lint.js:182:18
OpenAPI 3.x detected

ok.yaml
 26:20  warning  valid-example  "0.example" property type should be integer

✖ 1 problem (0 errors, 1 warning, 0 infos)

But.. hm, yeah, I think I'll try to narrow the validation to places where example can exist. I think I was wrong in assuming that example will be put (by users) only in places where it should be put.

chris-miaskowski · 2019-08-23T14:13:34Z

@philsturgeon, given this spec (that has your example included):

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  description: Swagger Petstore
  license:
    name: MIT
  contact:
    name: Test
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    get:
      summary: Info for a specific pet
      description: pets
      operationId: showPetById
      tags: [pets]
      parameters:
        - in: query
          name: petId
          required: true
          description: The id of the pet to retrieve
          schema:
            type: integer
          example: "3"
      responses:
        '200':
          description: Expected response to a valid request

I get:

Adding OpenAPI 3.x functions
Method `addRules` has been deprecated since version 4.1, use `loadRuleset` instead.
    at /snapshot/spectral/dist/cli/commands/lint.js:182:18
OpenAPI 3.x detected

ok.yaml
 26:20  warning  valid-example  "0.example" property type should be integer

✖ 1 problem (0 errors, 1 warning, 0 infos)

But.. hm, yeah, I think I'll try to narrow the validation to places where example can exist. I think I was wrong in assuming that example will be put (by users) only in places where it should be put.

One comment to add to this is as far as I remember the original request asked for error rather than warning, right?

lag-of-death · 2019-08-23T14:22:38Z

@chris-miaskowski, thanks, yes, it should be reported as errors

chris-miaskowski · 2019-08-23T14:26:33Z

src/rulesets/oas3/index.json

@@ -83,7 +83,20 @@
      "message": "{{error}}",
      "recommended": true,
      "type": "validation",
-      "given": "$..[?(@.example)]",
+      "given": "$..[?(@.example && !@.type)]",


I was about to suggest that you could try narrowing it down by schema but then I realized it won't work out of the box. There would still be a corner case where someone has an example but didn't provide a schema.

On a second thought I will suggest it :)

Suggested change

"given": "$..[?(@.example && !@.type)]",

"given": "$..[?(@.example && !@.schema)]",

If I understand this query correctly it will match all 'nodes' that have example but doesn't have schema next to it. This could mean two things:

either the example you found is inside the schema

or the example should be next to schema but that schema was not provided!

If it was not provided you will get undefined but that's fine because you should be able to check that in the actual rule implementation.

chris-miaskowski · 2019-08-23T14:27:25Z

src/rulesets/oas3/index.json

+      "summary": "Examples must be valid against their type.",
+      "message": "{{error}}",
+      "type": "validation",
+      "given": "$..[?(@.example && @.type)]",


ditto

The problem with type is that I'm not sure there isn't a nasty corner case where that would fail.

chris-miaskowski

Hey @lag-of-death very good write up, helped me grasp the context of this PR very quickly!
Re the code I don't see why it wouldn't work but I don't have a prove that it works because it lacks tests ;)
I'm rejecting until tests are added.

I would like to see coverage for the following cases

parameters:
  - in: query
    name: petId
    required: true
    schema:
      type: integer
    example: "3"

^ should give error

parameters:
  - in: query
    name: petId
    required: true
    example: "3"

^ should be OK

parameters:
  - in: query
    name: petId
    required: true
    schema:
      type: integer
      example: "3"

^ should give error

parameters:
  - in: query
    name: petId
    required: true
    schema:
      example: 123

^ should be ok (?)

parameters:
  - in: query
    name: petId
    required: true
    schema:
      type: object
      required:
        - a
        - b
      example: { a: 1 }

^ should give error

parameters:
  - in: query
    name: petId
    required: true
    schema:
      type: object
      required:
        - a
        - b
    example: { a: 1 }

^ should give error

Also there is something interesting I found about MediaTypeObject but I don't think we need to care about this now (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#media-type-object)

Furthermore, if referencing a schema which contains an example, the example value SHALL override the example provided by the schema.

lag-of-death · 2019-08-23T14:42:40Z

thanks @chris-miaskowski, I will add the tests 👍
about:

Furthermore, if referencing a schema that contains an example, the example value SHALL override the example provided by the schema.

I have stumbled upon this, but my understanding was rather that example value should take precedence over that of scheme.example when generating a response for example. But still, even if scheme.example is overwritten, it ought to be validated. Not sure though, but basically was following this logic.

P0lip · 2019-08-23T17:02:32Z

src/rulesets/oas3/index.json

@@ -83,7 +83,20 @@
      "message": "{{error}}",
      "recommended": true,
      "type": "validation",
-      "given": "$..[?(@.example)]",
+      "given": "$..[?(@.example && !@.type)]",


Once we are at it, is there any way to make the json path expression more specific?
I understand $..[?(@.example && !@.type)] feels very handy, yet it's utterly slow to the point where we have that rule turned off in Studio.
The other issue I see with that expression is the use of function filter expression that accesses the properties (@.example && @.type). This will pretty much impossible to support when #437 becomes a thing.

If there is no way to make it less general, I'm okay with leaving it as is.

Yeah I was trying to get more specific and less greedy rules like intentionally pretending with “parameters” so we know we’re looking st parameters and can make the rules more specific seeing as different types of parameters may or may not have a schema keyword, etc.

P0lip · 2019-08-23T17:03:05Z

src/rulesets/oas3/index.json

+        }
+      }
+    },
+    "valid-type-example": {


Should it be a recommended rule, or no?
I'd rather disabled by default.

We can make it not recommended until we are more confident with it, and bump it up in v5?

philsturgeon · 2019-08-24T06:47:28Z

Bang on I need to double check the contents of the message @chris-miaskowski wrote I’m pretty sure it’s not entirely correct.

We are definitely not talking about media type objects so don’t worry about that.

# Conflicts: # src/rulesets/oas/index.json

philsturgeon · 2019-08-28T09:24:13Z

src/rulesets/oas/__tests__/valid-example.ts


 // @oclif/test packages requires @types/mocha, therefore we have 2 packages coming up with similar typings
 // TS is confused and prefers the mocha ones, so we need to instrument it to pick up the Jest ones
 declare var test: jest.It;

 describe('valid-example', () => {
  const s = new Spectral();
-  s.setRules({


setRules is a handy new way of doing things that simplifies the API a little, and addRules is deprecated now.

Also the convention here has been for __tests__/{foo}.ts to match the rule name it is testing, but this test file is now testing two different rules.

@P0lip can explain a bit more about the recent changes in the spectral develop branch if you are not aware of what has happened in PRs like #430.

thanks, I don't know how to load a single rule with loadRuleset, is it possible @P0lip ?

I said setRules not loadRuleset. 😅

ah, yes, sorry. My bad

chris-miaskowski · 2019-08-28T13:26:47Z

Hey @philsturgeon , @lag-of-death I double check one of the examples I provided
parameters:
  - in: query
    name: petId
    required: true
    example: "3"
I said it "should be OK" but according to https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameterObject type is a required field.
Which means... not sure what. We should probably say it's NOT ok, but at the same time it looks like this situation in undefined.
WDYT?
@chris-miaskowski, from what I know, Parameter Object does not have .example keyword in OAS2, it's possible in OAS3 though. And types is only required if in !== 'body'

Bummers! Yes, you are right I looked at the incorrect doc!

OAS3 says

The example SHOULD match the specified schema and encoding properties if present
It doesn't say it MUST, though. So I guess my example is valid (???) @philsturgeon @lag-of-death

lag-of-death · 2019-08-28T13:36:50Z

@chris-miaskowski, from the spec:

The encoding object SHALL only apply to requestBody objects when the media type is multipart or application/x-www-form-urlencoded

from this PR's description:

But, OAS3 talks about validating example(s) against its encoding. This is vary vague. Encoding, it seems, is defined in Encoding Object and Encoding Object is only to be found in Media Type Object (so in Response/Request Object(s)). This might need further investigation and maybe should be handled later (not in this PR).

bottom line: didn't care about encoding as it would make this PR stuck in progress/review for ages

Also, I think that SHOULD match the specified schema and encoding properties if present. This answers it (although it is a bit vague). But, since you have no .schema, then your example is valid

philsturgeon · 2019-08-28T13:53:45Z

@chris-miaskowski The Encoding Object lives inside the Media Type Object which does have example and examples but remember that this PR is not about Media Type Object example/examples. That example is the Example Object found here.

This is about the example keyword that lives in parameters and inside schema and has nothing to do with encoding.

P0lip

Why did we end up with >5 rules? 🤔

P0lip · 2019-08-28T15:38:10Z

src/rulesets/oas3/index.json

@@ -78,6 +78,111 @@
        }
      }
    },
+    "valid-oas-example-in-parameters": {


Whoah, whoah, whoah. Why so many rules.
We could create a custom function and utilize functionOptions.

@philsturgeon, I only added rules, like you said - no new functions. But maybe again I'm mistaken? cc @P0lip

We could have a valid-oas-example rule and simply instrument it using options, like so

# your ruleset valid-oas-example: [error, { in: [parameters, headers, content] # etc }]

sorry @P0lip, I don't quite follow, where ^ would go?

@P0lip there are a lot of different ways in which examples can show up, so we were trying to get them done sharing the same generic schemaPath function, as the only difference between most of the types of differences are example and schema are siblings, or example is nested inside schema, or both, and that's just parameters.

This PR ignores Media Type Object example or examples as explained elsewhere.

@P0lip this PR has been going on for a long time and people have wandered in and started asking lots of questions, then we've explained it, then we have started the process over again with another person. You should definitely get caught up but doing it all over text would take a fairly long time. If you two can have a call (or I can jump in too tomorrow) then it might be easiest.

parameters: - in: query name: petId required: true description: The id of the pet to retrieve schema: type: integer example: "3" example: "5"

Check the tests to see all sorts of examples of parameters in different places.

If you think it'll be drastically better for performance we can switch approaches another time and make osOas3ParameterExamples look for example in parameter objects and osOas3SchemaExamples that will go through all schema's that have examples nested anywhere in them or whatever.

There's a million ways to do this we just gotta pick one that works and that isn't slow. The performance issues were discovered after this approach was decided upon.

The performance issues were discovered after this approach was decided upon.

I have known for at least a month or so. I might have not communicated that though, so it's on me.

Yeah, I understand the background behind this PR and I and don't really want to prevent this PR from being merged. I am aware lots of folks are waiting for that. On the other hand, we are introducing plenty of new rules that will be disabled in Studio anyway until the performance thingy is completed, which, by the way, might require these rules to be rewritten anyway.

Let's sync tomorrow in the morning or so.
I believe a custom function based approach shouldn't take longer than half of a day / day, so we should be fine after all. Either way, as I said, I won't block this PR.
If you all really want to ship it, I'm fine with it. I'll just create a tech debt ticket to be addressed in 4.2 or 5.0 in such a case.

P0lip · 2019-08-28T15:38:58Z

src/rulesets/oas3/index.json

+      "recommended": true,
+      "severity": 0,
+      "type": "validation",
+      "given": "$..parameters..[?(@.example && @.schema)]",


Paths are too loose.

@P0lip, what path for OAS3 schema next to example in parameters you'd rather see? I can't think of anything better atm

I don't really know, but this is going to be utterly slow.
@philsturgeon can you think of anything better?

I was wondering about this. Would it be better performance wise to:

run on all parameters then check for example and schema keys

run on all parameters that have an example then check for schema

Or is it the $..parameters bit that's the problem? There is an issue where #272 points out there are different types of parameters in the Link Object so we don't want to double up on that mistake.

Or is it the $..parameters bit that's the problem?

Yeah, it's $..parameters that is the problem, if we could narrow it down a bit, that would be great.
I don't think we are interested in parameters under info object, are we?
If I am not mistaken, parameters are bound to an endpoint/path, so we could at least have paths there, i.e. $.paths..parameters.
I truly doubt we aim to validate every property with parameters key, so let's limit the scope as much as we can.

lag-of-death · 2019-08-29T08:15:58Z

hi @P0lip

For OAS2:

Parameters can be found in:

a) Path Item object -> LIKE $.paths.pets.parameters 
b) Operation Object -> LIKE $.paths.pets.get.parameters 
c) Parameters Definitions Object -> $.parameters

For OAS3:

Parameters can be found in:

a) Components Object -> $.components.parameters
b) Path Item Object  -> LIKE $.paths.pets.parameters
c) Operation Object  -> LIKE $.paths.pets.get.parameters

So, it seems like 3 rules (or two, one with path, and the other for the definitions) instead of one for both OAS2/OAS3. Or one custom rule you mentioned.

What I could do for this PR is to have these two rules instead of one. But I think it would be best to create that tech debt card and handle performance issues there, not here.

Maybe we can take a look at

spectral/src/rulesets/oas/index.json

Line 345 in 129a23d

"given": "$..parameters[*]",

too in that tech debt?

LMK :)
cc @philsturgeon

P0lip · 2019-08-29T09:34:59Z

parameter-description is turned off by default, so it's quite okay, but yeah, we should improve it as well.
Frankly speaking, the parameters case just feels like a perfect candidate for a custom oas2 and/or oas3 function.
Either way, I'm quite okay with leaving it as is for now.
Could perhaps dedupe some of the tests, i.e. the ones checking format and such - it's enough to have them in one place.

lag-of-death · 2019-08-29T11:06:25Z

@P0lip, tests:

reports invalid usage of %s format
does not report valid usage of %s format
does not report example mismatches for unknown AJV formats
are now to only be found in:
src/rulesets/oas3/__tests__/templates/_oas-example.ts
src/rulesets/oas3/__tests__/templates/_schema-example.ts
I've left them there because of the difference in .example location. LMK if this is enough :)

philsturgeon · 2019-08-29T12:15:37Z

@P0lip let's guide this one in for a landing and improve in v5.0 with cleverly made performant OAS2 and OAS3-specific custom functions. Can you make a ticket for that?

P0lip · 2019-08-29T12:17:02Z

@philsturgeon @lag-of-death

Can you make a ticket for that?

Coolio. Will do today.
Looking good for me then, let's merge it.

lag-of-death · 2019-08-29T13:14:18Z

@P0lip, @philsturgeon, @chris-miaskowski, can anyone approve?

P0lip

I believe this is good to go.
I'll leave the call to @philsturgeon once he addresses the comments I left.

P0lip · 2019-08-29T14:44:13Z

src/rulesets/oas2/index.json

+    "valid-example-in-parameters": {
+      "description": "Examples must be valid against their defined schema.",
+      "message": "{{error}}",
+      "recommended": true,


Does the rule have to be recommended? @philsturgeon
It's expensive, so if we can have it disabled by default, that'd be great.
If you find it particularly useful, I'm fine with leaving it as is.

This is a pretty important feature, people have reported spectral as broken when its not run, so leaving it to only people who need to know about it and turn it on seems... unideal. People can disable slow rules if they want but honestly Studio is probably one of the few scenarios where speed matters? (That comment may not age well, but for right now...)

People can disable slow rules if they want but honestly Studio is probably one of the few scenarios where speed matters?

Yeah, it's because of the UI. In case of CI it usually doesn't really matter whether linting takes 5 seconds or 20 seconds... unless you run out of memory which is what the issue is all about.
So in the end, if one lints a huge document, such as Sendgrid or Stripe, it will matter, as you will inevitably run out of memory.

Ok, lets get this feature in and it can be a bit slow, as we know we are working on #437 anyway.

Either way, let's just merge it.
I'll create a follow up ticket for this feature today

If anyone has their computer catch on fire im not paying the bill, but hopefully they can give us some beefy description docs to play with and we can use them for benchmarking.

If anyone has their computer catch on fire im not paying the bill, but hopefully they can give us some beefy description docs to play with and we can use them for benchmarking.

😆 we should be fine.
4.2 or 5.0 will certainly come with optimized performance, and in the meantime one can always disable the rules.

src/rulesets/oas2/index.json

src/rulesets/oas3/index.json

P0lip

Code looks okay to me.

I know it must have been a tough journey for you Matt, but you did it, so great job 💪

lag-of-death · 2019-08-29T15:21:23Z

@chris-miaskowski, can you approve / can I dismiss the request for changes?

philsturgeon · 2019-08-29T15:32:11Z

@lag-of-death yeah you can dismiss old reviews if you're confident you've done the thing.

the concerns are addressed

* feat: validate example keyword * tests: adjust tests * test: fix tests * test: fix tests * test: add tests * test: add tests * refactor: change it to test * refactor: remove tests

lag-of-death changed the title ~~[WIP] feat: handle example keyword~~ Handle example keyword validation Aug 21, 2019

lag-of-death added this to the Aug '19 milestone Aug 21, 2019

lag-of-death added the t/bug Something isn't working label Aug 21, 2019

lag-of-death requested a review from philsturgeon August 21, 2019 16:03

philsturgeon force-pushed the develop branch from 9fde408 to 132a843 Compare August 22, 2019 06:39

lag-of-death requested a review from P0lip August 23, 2019 08:47

philsturgeon mentioned this pull request Aug 23, 2019

Parameter with required and example fails valid-example rule #243

Closed

2 tasks

chris-miaskowski reviewed Aug 23, 2019

View reviewed changes

chris-miaskowski previously requested changes Aug 23, 2019

View reviewed changes

P0lip reviewed Aug 23, 2019

View reviewed changes

lag-of-death changed the title ~~Handle example keyword validation~~ [WIP] Handle example keyword validation Aug 27, 2019

lag-of-death force-pushed the feat/handle-example-keyword branch from 475f2bc to 6b13f3c Compare August 27, 2019 16:15

lag-of-death added 2 commits August 27, 2019 18:35

feat: validate example keyword

fb56e30

tests: adjust tests

4ae8cc3

lag-of-death force-pushed the feat/handle-example-keyword branch from 6b13f3c to 4ae8cc3 Compare August 27, 2019 16:50

lag-of-death added 2 commits August 28, 2019 10:10

Merge remote-tracking branch 'origin/develop' into dev

129a23d

# Conflicts: # src/rulesets/oas/index.json

test: fix tests

2d8eb04

philsturgeon reviewed Aug 28, 2019

View reviewed changes

test: fix tests

0086013

chris-miaskowski modified the milestones: Aug '19, Aug '19 Hardening Aug 28, 2019

test: add tests

552e4b8

lag-of-death requested a review from chris-miaskowski August 28, 2019 13:24

refactor: change it to test

aad7001

Merge branch 'develop' into feat/handle-example-keyword

9132cbf

P0lip reviewed Aug 28, 2019

View reviewed changes

Merge branch 'develop' into feat/handle-example-keyword

c54b65d

Merge branch 'develop' into feat/handle-example-keyword

a7093ef

lag-of-death mentioned this pull request Aug 29, 2019

Validate response examples when a response has no schema stoplightio/prism#495

Closed

refactor: remove tests

6171ae3

Merge branch 'develop' into feat/handle-example-keyword

ff892e4

P0lip reviewed Aug 29, 2019

View reviewed changes

Merge branch 'develop' into feat/handle-example-keyword

b10affd

P0lip approved these changes Aug 29, 2019

View reviewed changes

Merge branch 'develop' into feat/handle-example-keyword

a444433

lag-of-death merged commit 7e97be3 into develop Aug 29, 2019

lag-of-death deleted the feat/handle-example-keyword branch August 29, 2019 15:40

P0lip mentioned this pull request Aug 29, 2019

valid-example-* rules should be more performant #506

Closed

	"given": "$..[?(@.example && !@.type)]",
	"given": "$..[?(@.example && !@.schema)]",

Handle example keyword validation #472

Handle example keyword validation #472

Conversation

lag-of-death commented Aug 21, 2019 • edited Loading

TL;DR

Findings:

OAS2

example keyword

examples keyword

A spec

OAS3

example key to be found in:

required key to be found in:

the conflict

examples keyword

To be found in:

lag-of-death commented Aug 23, 2019

philsturgeon commented Aug 23, 2019 • edited Loading

lag-of-death commented Aug 23, 2019 • edited Loading

chris-miaskowski commented Aug 23, 2019

lag-of-death commented Aug 23, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chris-miaskowski left a comment • edited Loading

Choose a reason for hiding this comment

lag-of-death commented Aug 23, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philsturgeon commented Aug 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chris-miaskowski commented Aug 28, 2019

lag-of-death commented Aug 28, 2019 • edited Loading

philsturgeon commented Aug 28, 2019 • edited Loading

P0lip left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lag-of-death commented Aug 29, 2019

P0lip commented Aug 29, 2019

lag-of-death commented Aug 29, 2019

philsturgeon commented Aug 29, 2019

P0lip commented Aug 29, 2019

lag-of-death commented Aug 29, 2019

P0lip left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

P0lip Aug 29, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

P0lip Aug 29, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

P0lip left a comment • edited Loading

Choose a reason for hiding this comment

lag-of-death commented Aug 29, 2019

philsturgeon commented Aug 29, 2019

lag-of-death commented Aug 21, 2019 •

edited

Loading

`example` keyword

`examples` keyword

`example` key to be found in:

`required` key to be found in:

`examples` keyword

philsturgeon commented Aug 23, 2019 •

edited

Loading

lag-of-death commented Aug 23, 2019 •

edited

Loading

chris-miaskowski left a comment •

edited

Loading

lag-of-death commented Aug 28, 2019 •

edited

Loading

philsturgeon commented Aug 28, 2019 •

edited

Loading

P0lip Aug 29, 2019 •

edited

Loading

P0lip Aug 29, 2019 •

edited

Loading

P0lip left a comment •

edited

Loading