Regression in beta.58 for query generators #869
Comments
|
Thanks for raising this. |
|
@rholshausen do you know if there has been any recent activity on the Rust side that may have addressed this? Should we look to create an issue there / migrate this one? |
|
Is it forcing the output to V2 format? |
|
@wabrit any chance you could please share the whole pact file or your consumer code (or both, preferably)? |
|
Hi @mefellows do you mean the generated json file? |
|
Yes please! Also any relevant code snippets. |
|
Apologies for the delay, but I wanted to strip our "real" examples down to the bare essentials necessary to demonstrate the issue: Here's a simple contract (minus the actual test): note the presence of a single REST query parameter activeOnly whose value is expressed as provider state. import { MatchersV3, PactV3 } from '@pact-foundation/pact';
import path from 'path';
const { fromProviderState, integer } = MatchersV3;
const provider = new PactV3({
dir: path.resolve(process.cwd(), 'pacts'),
consumer: 'foo',
provider: 'bar'
});
provider
.given('FooBar')
.uponReceiving('a request')
.withRequest({
method: 'GET',
path: '/bar',
query: {
activeOnly: fromProviderState('${activeOnly}', 'true')
},
headers: { Accept: 'application/json' }
})
.willRespondWith({
status: 200,
headers: { 'Content-Type': 'application/json' },
body: {
id: integer(6),
version: integer(0),
}
});And here is the generated JSON pact. Note the expression The same expression occurs in the matching rules, but AFAIK that has not caused issues on the provider side. {
"consumer": {
"name": "foo"
},
"interactions": [
{
"description": "a request",
"providerStates": [
{
"name": "FooBar"
}
],
"request": {
"generators": {
"query": {
"$.activeOnly[0]": {
"expression": "${activeOnly}",
"type": "ProviderState"
}
}
},
"headers": {
"Accept": "application/json"
},
"matchingRules": {
"header": {},
"query": {
"$.activeOnly[0]": {
"combine": "AND",
"matchers": [
{
"match": "type"
}
]
}
}
},
"method": "GET",
"path": "/bar",
"query": {
"activeOnly": [
"true"
]
}
},
"response": {
"body": {
"id": 6,
"version": 0
},
"headers": {
"Content-Type": "application/json"
},
"matchingRules": {
"body": {
"$.id": {
"combine": "AND",
"matchers": [
{
"match": "integer"
}
]
},
"$.version": {
"combine": "AND",
"matchers": [
{
"match": "integer"
}
]
}
},
"header": {}
},
"status": 200
}
}
],
"metadata": {
"pact-js": {
"version": "10.0.0-beta.58"
},
"pactRust": {
"ffi": "0.2.2",
"mockserver": "0.8.7",
"models": "0.2.7"
},
"pactSpecification": {
"version": "3.0.0"
}
},
"provider": {
"name": "bar"
}
} |
|
I updated my version from PS: I tested with all the versions and I think it is happening since version |
|
Any update on this issue? I'm sorry for being so pushy, but this is blocking me to update the node version (from 16 to 19). Something that I really need to do :( |
No, sorry.
Why is the node version update tied to a Pact library upgrade? |
Hi, I cannot update to node 19 because this specific Pact release ( |
the latest version is |
Yes, but the version So I cannot use the |
|
Thanks for clarifying, I can see the challenge. Unfortunately I don't have an answer for when that bug will be resolved. @rholshausen this looks a bit like pact-foundation/pact-reference#238 (in that it's applied to an indexed value). Would you like me to create an issue on the pact reference project or is it OK to track here? |
|
@dianaDBB I got around this while still using beta with a "pre-process" step run on the generated consumer pacts just before the pacts are published (this is in a nodejs environment). Happy to share the small amount of js code I wrote if it would be of help to you. |
|
That's a great point and suggestion, thanks @wabrit! |
Oh, that would be amazing and would really help me out! Thank you @wabrit so much :) |
|
No problem @dianaDBB just let me know how best to send it (its about 30-50 lines IIRC) |
If you don't mind, I think it would be really great to the community if you shared it in a public way. For example, can you create a public git repository with that and then share the link here? Just because that way, everyone else that encounters with this issue will have a solution available. And again, thank you so much for the help :) |
|
np - here it is https://github.com/wabrit/pactjs-workaround |
|
Thank you @wabrit. Your solution worked! |
|
Having the same issue since several months now...any updates on when this might be fixed ? |
|
👋 Hi! The 'smartbear-supported' label has just been added to this issue, which will create an internal tracking ticket in PactFlow's Jira (PACT-787). We will use this to prioritise and assign a team member to this task. All activity will be public on this ticket. For now, sit tight and we'll update this ticket once we have more information on the next steps. |
mefellows
added
the
upstream
Software versions
Please provide at least OS and version of pact-js
Expected behaviour
With this contract:
I would expect to see (as output by e.g. beta51)
Actual behaviour
With beta.58 we get an output pact:
The key under query is now
$.id[0]instead of justid, which causes the provider verification to fail.The text was updated successfully, but these errors were encountered: