Open mefellows opened 3 months ago
OK this has exposed an issue, i'm not sure where it is yet.
Upon investigating, it seems that the following use cases stopped working - possibly they were only working because of the presence of the type matcher:
query strings:
2024-06-21T03:55:39.588275Z DEBUG tokio-runtime-worker pact_matching: --> Mismatches: [QueryMismatch { parameter: "accountNumber", expected: "{\"expression\":\"${accountNumber}\",\"value\":\"100\"}", actual: "100", mismatch: "Expected query parameter 'accountNumber' with value '{\"expression\":\"${accountNumber}\",\"value\":\"100\"}' but was '100'" }]
2024-06-21T03:55:39.588472Z DEBUG tokio-runtime-worker pact_mock_server::hyper_server: Request did not match: Request did not match - HTTP Request ( method: GET, path: /accounts/search/findOneByAccountNumberId, query: Some({"accountNumber": ["{\"expression\":\"${accountNumber}\",\"value\":\"100\"}"]}), headers: Some({"Accept": ["application/hal+json"]}), body: Missing ) 0) Expected query parameter 'accountNumber' with value '{"expression":"${accountNumber}","value":"100"}' but was '100'
Bodies:
2024-06-21T03:57:04.428658Z DEBUG tokio-runtime-worker pact_matching: --> Mismatches: [BodyMismatch { path: "$.accountNumber", expected: Some(b"{\"expression\":\"${accountNumber}\",\"value\":100}"), actual: Some(b"100"), mismatch: "Type mismatch: Expected 100 (Integer) to be the same type as {\"expression\":\"${accountNumber}\",\"value\":100} (Object)" }]
2024-06-21T03:57:04.428951Z DEBUG tokio-runtime-worker pact_mock_server::hyper_server: Request did not match: Request did not match - HTTP Request ( method: POST, path: /accounts/search/findOneByAccountNumberIdInBody, query: None, headers: Some({"Content-Type": ["application/json"], "Accept": ["application/hal+json"]}), body: Present(63 bytes, application/json) ) 0) $.accountNumber -> Type mismatch: Expected 100 (Integer) to be the same type as {"expression":"${accountNumber}","value":100} (Object)
And presumably headers (I don’t have a test for this).
The only one that works is when it's used in a path
expression.
It looks like the expression is not being set properly, as you can see the JSON format instead of the expected value.
The type matcher may have hidden this issue.
Fixes #1088
This is an unfortunate solution, but works. It exposes a type/logic flaw, in that generators are considered a type of Matcher, which they are not. This should be rectified in a future major release.