Undesired property injected in the generated response schema of array type

I noticed that a property maxItems: 2 was injected to the generated response schema despite not being present in the original definition. I tried to narrow down the issue and arrived at a trimmed version of the Swagger Petshop.

Giving this as input to portman (both files are attached):

> portman -l petshop-api-bug.yaml -o ./petshop-api-bug-postman.json
======================================
 Local Path:            petshop-api-bug.yaml
 Output Path:           ./petshop-api-bug-postman.json
 Portman Config:        portman-config.default.json
 Postman Config:        postman-config.default.json
 Environment:           .env
 Inject Tests:          true
 Run Newman:            false
 Newman Iteration Data: false
 Upload to Postman:     false  
======================================
  ✔ Conversion successful
======================================
🚀 Collection written to: ./petshop-api-bug-postman.json 🚀
======================================

While successful, it generates this schema (pretty printed):

// Response Validation
const schema = {
  "type": "array",
  "items": {
    "required": [
      "name"
    ],
    "properties": {
      "id": {
        "type": "integer",
        "example": 10
      },
      "name": {
        "type": "string",
        "example": "doggie"
      },
      "status": {
        "type": "string",
        "description": "pet status in the store",
        "enum": [
          "available"
        ]
      }
    },
    "type": "object"
  },
  "maxItems": 2
}

Notice the last property.

Possible cause and a workaround

If you look at response test generation code, you can see that traverse in convertUnsupportedJsonSchemaProperties explicitly checks for and deletes minItems: 2 and maxItems: 2. A comment reveals another part of the conversion is known to inject these unwanted properties.

The branching condition, specificallyobj[k]?.type === 'array', hints that this is is only an issue when the type is set to array. However, if the schema has an array as the outermost type, for instance

schema:
  type: array
  items: 
    $ref: '#components/MyItems'

as in my example, then we’d never check for f the first loop immediately iterates over the keys type and items.

The workaround

If my guess of the cause is correct, just changing the schema to begin with an object instead of an array type should be enough to make traverse see the array and delete the maxItems field.

Modified response schema in petshop-api-bug.yaml:

schema:
    type: object
    required:
      - pets
    properties:
      pets:
        type: array
        items:
          $ref: '#/components/schemas/Pet'

And this works. The generated schema is now:

{
  "type": "object",
  "required": [
    "pets"
  ],
  "properties": {
    "pets": {
      "type": "array",
      "items": {
        "required": [
          "name"
        ],
        "properties": {
          "id": {
            "type": "integer",
            "example": 10
          },
          "name": {
            "type": "string",
            "example": "doggie"
          },
          "status": {
            "type": "string",
            "description": "pet status in the store",
            "enum": [
              "available"
            ]
          }
        },
        "type": "object"
      }
    }
  }
}

Versions

> portman --version
1.8.0

On Ubuntu 20.04 LTS running under WSL.

Attachments

petshop-api-bug.zip

[thim81]

@adnilsson We have a fix ready. I’ll add some more tests to include it in our test coverage and put it in a PR.

The generated JSON schema result would be:

{
   "type":"array",
   "items":{
      "required":[
         "name"
      ],
      "properties":{
         "id":{
            "type":"integer",
            "example":10
         },
         "name":{
            "type":"string",
            "example":"doggie"
         },
         "status":{
            "type":"string",
            "description":"pet status in the store",
            "enum":[
               "available"
            ]
         }
      },
      "type":"object"
   }
}

The fix will most likely land in the next release.

[thim81]

@jonathanevans-freesat Thanks for reporting it. Something went wrong with the build, so apologies for the inconvenience. Going to close the issue.