hey there, I'm having trouble matching my queries to the oas files in bidirectional contract testing, details in thread

Just sheer curiosity: why are you building a custom tool to do this? What should it do that https://bitbucket.org/atlassian/wiremock-pact-generator/src/master/ doesn’t?

hey there! Valid point, we did look at the available tools first of course, but we were unable to use that one because it's java-only based, limits one provider per wiremock server and has not been actively supported for seemingly a few years

Gotcha! Just wanted to make sure you've seen that. Are you working on a general-purpose WireMock adapter (because you mentioned Java-only)? The not-so-active support is a valid point, indeed. I'll ask around and see if people know more about this. I'm running a test with the latest WireMock version right now just to see if it still works as it used to.

hey, I had an issue with the contract not being valid without the values placed in arrays, as it seems to have been (or still is) a bug with the validation in pact, it was raised here a while back. Or do you mean I should put the matcher in an array as well? even though the query object in the OAS file is not in array for each value?

Just for reference, this is the contract that I just generated, and Pactflow accepts it:

{
  "consumer": {
    "name": "order_consumer"
  },
  "provider": {
    "name": "payment_provider"
  },
  "interactions": [
    {
      "description": "GET /payment/this_is_not_a_valid_payment_id -> 400",
      "request": {
        "method": "GET",
        "path": "/payment/this_is_not_a_valid_payment_id",
        "headers": {
          "content-length": "0",
          "connection": "close",
          "accept-encoding": "gzip, x-gzip, deflate",
          "accept": "application/json, application/*+json",
          "user-agent": "Apache-HttpClient/5.2.1 (Java/17.0.3.1)"
        }
      },
      "response": {
        "status": 400
      }
    },
    {
      "description": "GET /payment/00000000-0000-0000-0000-000000000000 -> 404",
      "request": {
        "method": "GET",
        "path": "/payment/00000000-0000-0000-0000-000000000000",
        "headers": {
          "content-length": "0",
          "connection": "close",
          "accept-encoding": "gzip, x-gzip, deflate",
          "accept": "application/json, application/*+json",
          "user-agent": "Apache-HttpClient/5.2.1 (Java/17.0.3.1)"
        }
      },
      "response": {
        "status": 404
      }
    },
    {
      "description": "GET /payment/228aa55c-393c-411b-9410-4a995480e78e -> 200",
      "request": {
        "method": "GET",
        "path": "/payment/228aa55c-393c-411b-9410-4a995480e78e",
        "headers": {
          "content-length": "0",
          "connection": "close",
          "accept-encoding": "gzip, x-gzip, deflate",
          "accept": "application/json, application/*+json",
          "user-agent": "Apache-HttpClient/5.2.1 (Java/17.0.3.1)"
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "content-type": "application/json"
        },
        "body": {
          "id": "8383a7c3-f831-4f4d-a0a9-015165148af5",
          "orderId": "228aa55c-393c-411b-9410-4a995480e78e",
          "status": "payment_complete",
          "amount": 42,
          "description": "Payment for order 228aa55c-393c-411b-9410-4a995480e78e"
        }
      }
    }
  ]
}

Without more specific details about element value matching rules, I assume Pactflow matches on type.

matching rules are not considered in the bi directional comparison so adding them to the contract is unnecessary

Bas, I'm not seeing a query in your contract, which is what I'm having the issue with

By

query

you're referring to query parameters, right? Sorry, I'm not fluent in OpenAPI spec 🙂

sorry yes, query parameters

Yes, I'm familiar with them, just not with how they're described in OpenAPI

removing the array surrounds around query values in the contract leads to the old

requestQuery[queryName].join is not a function

issue, which was raised in the past

I'm trying to reproduce this in my own project right now, just to see what happens 🙂

my gen debugging process 1. get pact and oas 2. check oas is valid 3. check pact is valid 4. run against swagger-mock-validator repo directly https://github.com/pactflow/swagger-mock-validator 5. I would also check the pact contract generated with pact framework itself just to ensure no issues with our manually generated one can then hack on the smv codebase to demonstrate issue and tweak code to support, if it doesn’t already

Changed path to query parameter, this is what the contract generated by WireMockPactGenerator looks like now:

{
  "consumer": {
    "name": "order_consumer"
  },
  "provider": {
    "name": "payment_provider"
  },
  "interactions": [
    {
      "description": "GET /payment -> 400",
      "request": {
        "method": "GET",
        "path": "/payment",
        "query": "order=this_is_not_a_valid_payment_id",
        "headers": {
          "content-length": "0",
          "connection": "close",
          "accept-encoding": "gzip, x-gzip, deflate",
          "accept": "application/json, application/*+json",
          "user-agent": "Apache-HttpClient/5.2.1 (Java/17.0.3.1)"
        }
      },
      "response": {
        "status": 400
      }
    },
    {
      "description": "GET /payment -> 404",
      "request": {
        "method": "GET",
        "path": "/payment",
        "query": "order=00000000-0000-0000-0000-000000000000",
        "headers": {
          "content-length": "0",
          "connection": "close",
          "accept-encoding": "gzip, x-gzip, deflate",
          "accept": "application/json, application/*+json",
          "user-agent": "Apache-HttpClient/5.2.1 (Java/17.0.3.1)"
        }
      },
      "response": {
        "status": 404
      }
    },
    {
      "description": "GET /payment -> 200",
      "request": {
        "method": "GET",
        "path": "/payment",
        "query": "order=228aa55c-393c-411b-9410-4a995480e78e",
        "headers": {
          "content-length": "0",
          "connection": "close",
          "accept-encoding": "gzip, x-gzip, deflate",
          "accept": "application/json, application/*+json",
          "user-agent": "Apache-HttpClient/5.2.1 (Java/17.0.3.1)"
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "content-type": "application/json"
        },
        "body": {
          "id": "8383a7c3-f831-4f4d-a0a9-015165148af5",
          "orderId": "228aa55c-393c-411b-9410-4a995480e78e",
          "status": "payment_complete",
          "amount": 42,
          "description": "Payment for order 228aa55c-393c-411b-9410-4a995480e78e"
        }
      }
    }
  ]
}

thanks Bas - if it works on your end I'll update mine to include the query as just a string rather than object ; curious how it treats multiple parameters though? assuming

&

would be accepted in this case

Happy to test that too once provider side verification works

Thanks a lot Bas, I'll try it out on my end and see how goes

Legend as always @Bas Dijkstra!

I'm learning here, too 🙂

yep tried the multiple ones, in pactflow they are happily coming through as an object, but it's still not matching to the object as defined in OAS upside down tears

When I remove the second query parameter from the consumer-side contract (so that only has one) but the OAS requires both, I get a validation error (as expected):

aha

Yes, that's what I thought

all the required properties that is - the main difference I assume is that some properties have enum/pattern defined there

I think so, too

well then that's a bummer - @Yousaf Nabi (pactflow.io) I can see from the link that it's not currently comparing beyond primitive types, and guessing there's no way to force it?

Yeah. Pact Matchers are not used in BDCT comparison. All that is matched are the example values in the pact file against the schema in the BDCT.

hey Matt, are the snippets are posted earlier not sufficient?

Yes, I can see how that error message is confusing, I reproduced this by using a provider OAS that requires two query parameters and then providing only one on the consumer side. The other way around worked fine (sending two as the consumer, requiring only one as the provider) but that is as expected.

little update, I have removed all enum/pattern/min max definitions from the OAS file, but the error still remains and it's not matching up the parameters. The other theory is maybe the queries defined as objects are not working? will rewrite it as individual params and check

Do you have an example of a working request / endpoint?

parameters defined without a reference work:

"parameters": [
          {
            "name": "amount",
            "in": "query",
            "required": true,
            "schema": {
              "type": "number"
            }
          },
          {
            "name": "buy_currency",
            "in": "query",
            "required": true,
            "schema": {
              "maxLength": 3,
              "minLength": 3,
              "type": "string"
            }
          },
          {
            "name": "sell_currency",
            "in": "query",
            "required": true,
            "schema": {
              "maxLength": 3,
              "minLength": 3,
              "type": "string"
            }
          },
          {
            "name": "fixed_side",
            "in": "query",
            "required": true,
            "schema": {
              "type": "string",
              "enum": [
                "buy",
                "sell"
              ]
            }
          },
          {
            "name": "delivery_date",
            "in": "query",
            "required": true,
            "schema": {
              "type": "string"
            }
          },
          {
            "name": "tenor",
            "in": "query",
            "required": true,
            "schema": {
              "pattern": "tod|tom|spot|forward",
              "type": "string"
            }
          }
        ]

Yes, that's what I think, too. But I also think the two schemas are different, so it's only logical. One defines a single, complex query parameter (complex meaning having an object value) and the other having multiple, simple query parameters (simple meaning having a primitive value). It's only logical that only one of them works, not the other. That's why I was asking if you could show (the relevant part of) an actual, working request endpoint for your provider, partly out of curiosity (never worked with complex query parameters), partly because it helps define the consumer expectations in the right way, partly because then we can see which of the two OAS variants is the right one

host:port/v1/quotes?amount=113&buy_currency=SGD&sell_currency=AUD&fixed_side=buy&delivery_date=2024-04-15&tenor=spot' \

+ headers normally works

Assuming you're using OpenAPI 3.x, I think the problem might be (I'm cautious here) that from the schema the processor doesn't know how to process the query parameter. See this SO answer here: https://stackoverflow.com/a/51277233 If you add

"style": "form"

and

"explode": true

to the schema, would that make it work?

thanks Das, I'll test it out!

s/Das/Bas 😛

Would love to hear if adding those fields to the spec made it work, @Milda :)

sorry guys having a day off today, but the explode parameter didn't work on Friday - I'll have more of a look tomorrow though