hi guys, I’m trying to implement bi-directional te...
# pactflow
p
hi guys, I’m trying to implement bi-directional testing PoC with pactflow and I have noticed the following problem: in my
swagger.json
I have the field with
"format" : "S2S-Token"
(this is our custom token) and pactflow fails with during verification:
Copy code
Validator Error unknown format "S2S-Token" is used in schema at path "#/properties/value"
even though I have required headers and payload in request, looks like pactflow does not like this custom format field, is there a way to fix this?
👍 1
m
Can you share your OAS? IF not here, could you please send a request to support@pactflow.io so we can take a look?
y
Hey @Pavlo Sprogis, does your
format
property have an associated primitive
type
? https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#data-types
assuming you are using oas2
m
(also, side note, love the avatar!)
🙂 1
p
Can you share your OAS?
I will ask the team and management, since we have plenty of regulations, soc compliance, etc. That’s why I removed information about all endpoints and left only 1 for testing
Hey @Pavlo Sprogis, does your
format
property have an associated primitive
type
?
yes, it is string:
{ “name” : “name here”, “in” : “header”, “description” : “authentication key”, “required” : true, “type” : “string”, “format” : “S2S-Token”
Copy code
}
m
Does it validate here: https://editor.swagger.io/?
p
yes, I do not see any errors, only warnings: “siblings values alongside $refs are ignored. ”
but no complains about format: s2s-token
assuming you are using oas2
yes, correct,
"swagger" : "2.0",
y
I've managed to recreate with
openapi: 3.0.3
will upload an example on a PR to view and test
👍 1
p
wow, great, thank you!
y
c
@Matt (pactflow.io / pact-js / pact-go) is there any chance PactFlow may take "ownership" of the "Atlassian owned" Open Source swagger-mock-validator project? I had opened this defect nearly 15 months ago when our company started running into it, but to date it doesn't seem to have been worked on. There's another issue in particular that had a lot of comments that I believe should ideally result in an enhancement idea for this compare tool as well: https://bitbucket.org/atlassian/swagger-mock-validator/issues/84/test-incorrectly-passes-when-mock-expects where we should auto add "additionalProperties=false" to every object in the api-spec just before the compare happens similar to how it already strips the "required" flag off of every property in the spec because consumers may not want to utilize every property.
additionalProperties=false should be added to any/every object that doesn't already have an additionalProperties value specified. It makes sense for OAS to default that value to true, but for this compare tool specifically, it makes sense for that value to default to false.
👍 1
y
I'm with you and Tim on this one for sure. I had that same issue before and it seemed like such a gap, from the validation from the Pact side of the fence
m
We are likely to fork that project soon Craig as we use it in our BDCT feature, and need to support v3 and v4 pacts properly
I think there are issues with that tool that can be overcome without a significant rewrite. For example, polymorphic payloads aren’t supported (e.g.
anyOf
,
oneOf
etc.)
I spiked an alternative about a year ago using modern OAS parser, and was able to overcome this issue fairly easily. There are no doubt other issues we’ll need to overcome, but I think because Atlassian built it a while ago retrofitting that behaviour is both a) difficult to do and b) potentially going to impact their usage of the tool.
additionalProperties=false should be added to any/every object that doesn’t already have an additionalProperties value specified. It makes sense for OAS to default that value to true, but for this compare tool specifically, it makes sense for that value to default to false.
In the context of our BDCT feature, I’m not convinced that tool should do that or if Pactflow should pre-validate it. I could definitely see it having a flag however that controls the behaviour
c
Yeah, I think that's probably ideal, to have an option to run the swagger-compare with additionalProperties defaulted to false, so users can have the choice at execution time. Forking the repo and taking control of that fork also sounds like the best solution both for PactFlow and the community. As pact continues to makes changes in the future, especially now with so many people implementing BDCT, you're going to want to make sure that any breaking changes pact implements with new major versions still have a way to get compared successfully to OAS.
💯 1
☝️ 1
m
BDCT is already starting to resonate with our customers and prospects, so we’ll definitely need to deal with it soon anyway
We also “drink our own champagne” and do our best to feel the pains of our customers. The lack of some validation like
additionalProperties
and others will need adressing. As we move beyond OAS, the formula will also mature
c
As mentioned in the issue ticket I posted, setting
additional properties=false
will do a strict compare, but specifying that in the actual OAS may not be what you want all the time (and teams may forget or not know to). It sounds like you have a good direction on this. It's exciting to see two of the biggest issues I've been having with pact-swagger compares for over a year get some traction toward resolutions.
🙏 1
m
For transparency, I think we could address the
additionalProperties
more quickly than the other. But we definitely need to solve both
thanks for the inspiration!!
y
Hey, had a go at fixing this and we have a fork now, although it is on GH, the original repo is on BB, but we can still track changes. https://github.com/pactflow/swagger-mock-validator https://www.npmjs.com/package/@pactflow/swagger-mock-validator Next steps are to pull into the Pactflow application, and add support for v3/v4 Pacts Will look at getting the additionalProp change in, as a configuration option both in the tool, and in Pactflow land.
🎉 1
m
👏 Yousaf - brought this forward for us. We’ll aim to get this into the next BDC release
y
Hey @Pavlo Sprogis, this change went out with the Pactflow platform yesterday, so you should able to retest, I haven't checked it since deploying (I've just got up) but tested with your test case prior to release, so 🤞 should be good
👍 2
🙌 1
m
FYI Pactflow now automatically sets
additionalProperties
to false during verification (the package above also now has an additional flag to conditionally set this if required)
y
p
great, thank you!