hello~, we noticed some problems with failing contracts. There were previously no issues, a POST endpoint accepted a

application/x-www-form-urlencoded

request, it was defined as per the OAS3 spec (

type: object

, then key-value pairs as properties) and sent as key-value pairs, string format, by the consumer; i.e.

"key=value&key2=value2"

. Issue arose when adding a 2nd request body option for an

application/json

. Now, all of a sudden, the contract interaction that worked previously (for

x-www-form-urlencoded

) is failing, saying the request body must be an object. A new interaction for the

application/json

works (with a json request body), but the old one (form) does not. Both

application/json

and

application/x-www-form-urlencoded

are expected to work, as long as one of them is provided for the POST request. Any ideas on whether this is an error on our end or a bug in the swagger validator? Relevant bits of code: Consumer contract relevant part (looks the same when passing and when failing w/ application/json):

"request": {
        "method": "post",
        "path": "/transfers/create",
        "headers": {
          "X-Request-Id": "96c21705-fbea-4be0-8e3f-6b9543cad0d7",
          "Content-Type": "application/x-www-form-urlencoded"
        },
        "body": "source_account_id=a66ca63f-e668-47af-8bb9-74363240d781&destination_account_id=22ed17b5-b90c-424e-aa78-d24928b1778e&currency=USD&amount=150.00&reason=reason&unique_request_id=58e78791-e0e5-012c-2dee-001e52f3c730&request_id=96c21705-fbea-4be0-8e3f-6b9543cad0d7"
      },

OAS schema old (worked)

requestBody:
        required: true
        content:
          application/x-www-form-urlencoded:            
            schema:
              type: object
              properties:
                request_id:
                  type: string
                  description: The request ID used for tracing requests set in the request body
                principal_identifier:
                  $ref: "#/components/schemas/PrincipalIdentifier"
                source_account_id:
                  description: Account UUID of the paying account.
                  type: string
                  format: uuid
                destination_account_id:
                  description: Account UUID of the receiving account.
                  type: string
                  format: uuid
                currency:
                  description: Three-letter ISO currency code.
                  type: string
                  pattern: '^[A-Z]{3}$'
                amount:
                  description: Amount
                  type: string
                  format: decimal
                  pattern: '^(\d+(\.\d{1,3})?)$'
                reason:
                  description: User-generated reason for transfer, freeform text.
                  type: string
                  maxLength: 255
                unique_request_id:
                  description: User-generated idempotency key. The value must be 100 characters or fewer.
                  type: string
                  maxLength: 100
              required:
                - source_account_id
                - destination_account_id
                - currency
                - amount

New schema reuses the same schema, just adding an extra content type, i.e.

requestBody:
        required: true
        content:
          application/x-www-form-urlencoded:
            schema:
              $ref: "#/components/schemas/<schema>"
          application/json:
            schema:
              $ref: "#/components/schemas/<schema>"

error:

Request body is incompatible with the request body schema in the spec file: must be object

Ta!

Hmm interesting. We don’t actually check the bodies of

x-www-form-urlencoded

bodies, at least not according to our docs:

thinking2 any ideas on what might be up then?

I can reproduce it, now to figure out why it’s a problem

want me to raise an issue on the swagger repo Matt?

thanks, hold off for a little bit - I’ll tinker for a few more mins before I close the laptop for the night

ok ta, I appreciate it's a pretty quiet time currently so we're fully expecting it not to be resolved until next year 😄

so I won’t ask you to create the GH issue, but could I please ask you to create a case? I’ll give the team a heads up, and link this issue to it: https://github.com/pactflow/bdct-oas-examples/issues/2

case being a support ticket yes?

oops, moved issue to the right place: https://github.com/pactflow/swagger-mock-validator/issues/71

gotcha

It may not get looked (the detailed issue) at until after xmas, but it’s possible. But you’ll get an immediate response from the engineering team / me to say that the issue is the above thing and then the Customer Care folks will reach out once we’ve linked it. Having a customer care ticket will ensure better visibility and pressure on us to get it resolved 🙂

no need for the pressure around this time of year 😄 but I get your point. Will raise it now and link the issue in the description. thanks!

FYI we’ve updated the validator to support parsing and validating the form bodies now also. The repro in the issue above now passes. Note that you may find some tests failing if they used form validation before as we didn’t previously compare bodies. The change is yet to go live in PactFlow, but wanted to give you the heads up (you should get a response by customer care when it is released). You can test using the CLI above directly though in the meantime should you want to

thanks Matt, appreciate it

Yes! It should be in production now already

hmm, seems we're still seeing those issues, was it limited to a particular method type, ie GET only or similar?

I think you’ll need to push a new version of the provider (or consumer) for the verification to update. We don’t go back and re-run existing comparisons, to avoid altering history. Just checking you’ve done that?

I'll check if it's been re-published

Hmm

shared in dm