Matt (pactflow.io / pact-js / pact-go)
Yousaf Nabi (pactflow.io)
Yousaf Nabi (pactflow.io)
sameena syed
12/15/2022, 6:16 AM<<< FAILURE! - in io.pact.example.grpc.maven.PactConsumerTest
calculateRectangleArea{MockServer, SynchronousMessages} Time elapsed: 1.542 s <<< ERROR!
kotlin.UninitializedPropertyAccessException: lateinit property process has not been initialized
at io.pact.example.grpc.maven.PactConsumerTest.calculateRectangleArea(PactConsumerTest.java:45)
sameena syed
12/20/2022, 8:25 AMpact-plugin-cli.exe install <https://github.com/sameena-ops/pact-sample-plugin/releases/tag/v0.0.5>
Installing plugin pact-sample-plugin version 0.0.4
✔ Plugin with name 'pact-sample-plugin' and version '0.0.4' already exists. Overwrite it? · Yes
Error: Did not find a matching file pattern on GitHub to install
Sanjaya Kumar Sahoo
12/20/2022, 1:49 PMYousaf Nabi (pactflow.io)
Yousaf Nabi (pactflow.io)
Fábio Rodrigues
01/04/2023, 3:24 PMAdam Cox
03/21/2023, 12:05 PMTien Vo
03/25/2023, 4:07 AMTien Vo
03/25/2023, 4:02 PMpact_ffi::plugins: Failed to call out to plugin - Request to configure interaction failed: Failed to process protobuf: Failed to invoke protoc binary: exit code exit status: 1
According to this https://github.com/pactflow/pact-protobuf-plugin#logging, how can I set env LOG_LEVEL
exactly?
I checked /path/to/plugins/protobuf/log/*.log.Y-M-D
, all files are empty, and I can't see the real problem.
I tried this but it doesn't work:
LOG_LEVEL=debug PACT_LOGLEVEL=trace phpunit example/async-message/consumer/tests/Contract/
Tien Vo
03/27/2023, 1:46 AMPACT_PLUGIN_DIR
, or introduce new var PACT_PLUGIN_DIRS
Tien Vo
04/03/2023, 5:06 AM$response
->setStatus(200)
->setBody([
'csvHeaders' => true,
'column:id' => "matching(regex, '^[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}$','{$id}')",
'column:name' => "matching(type,'{$name}')",
'column:gender' => "matching(regex, 'male|female|other','{$gender}')",
])
->setContentType('text/csv')
;
Mock server will return:
gender,id,name
$gender,$id,$name
Is this expected behavior?Tien Vo
04/03/2023, 5:51 AMPACT_LOGLEVEL=debug phpunit example/provider/ 12:41:36
Xdebug: [Step Debug] Could not connect to debugging client. Tried: 127.0.0.1:9003 (through xdebug.client_host/xdebug.client_port).
PHPUnit 9.5.20 #StandWithUkraine
2023-04-03T05:41:46.951993Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_add_directory_source FFI function invoked
2023-04-03T05:41:46.952030Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_execute FFI function invoked
2023-04-03T05:41:46.952033Z DEBUG ThreadId(01) pact_ffi::verifier::handle: Pact source to verify = Dir(/home/myname/Projects/pact-php-csv/example/provider/tests/Contract/../../../broker/pacts)
2023-04-03T05:41:46.952639Z DEBUG ThreadId(01) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/content-generator/binary
core/content-generator/json
core/content-matcher/json
core/content-matcher/multipart-form-data
core/content-matcher/text
core/content-matcher/xml
2023-04-03T05:41:46.952667Z DEBUG ThreadId(01) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/matcher/v1-equality
core/matcher/v2-max-type
core/matcher/v2-min-type
core/matcher/v2-minmax-type
core/matcher/v2-regex
core/matcher/v2-type
core/matcher/v3-content-type
core/matcher/v3-date
core/matcher/v3-datetime
core/matcher/v3-decimal-type
core/matcher/v3-includes
core/matcher/v3-integer-type
core/matcher/v3-null
core/matcher/v3-number-type
core/matcher/v3-time
core/matcher/v4-array-contains
core/matcher/v4-equals-ignore-order
core/matcher/v4-max-equals-ignore-order
core/matcher/v4-min-equals-ignore-order
core/matcher/v4-minmax-equals-ignore-order
core/matcher/v4-not-empty
core/matcher/v4-semver
2023-04-03T05:41:46.952718Z DEBUG ThreadId(01) pact_verifier: Scanning "/home/myname/Projects/pact-php-csv/example/provider/tests/Contract/../../../broker/pacts"
2023-04-03T05:41:46.952871Z INFO ThreadId(01) pact_verifier: Pact file requires plugins, will load those now
2023-04-03T05:41:46.952881Z DEBUG ThreadId(01) pact_plugin_driver::plugin_manager: Loading plugin PluginDependency { name: "csv", version: Some("0.0"), dependency_type: Plugin }
2023-04-03T05:41:46.952894Z DEBUG ThreadId(01) pact_plugin_driver::plugin_manager: Did not find plugin, will start it
2023-04-03T05:41:46.952896Z DEBUG ThreadId(01) pact_plugin_driver::plugin_manager: Loading plugin manifest for plugin PluginDependency { name: "csv", version: Some("0.0"), dependency_type: Plugin }
2023-04-03T05:41:46.952902Z DEBUG ThreadId(01) pact_plugin_driver::plugin_manager: Looking for plugin in "/home/myname/.pact/plugins"
2023-04-03T05:41:46.953001Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_shutdown FFI function invoked
F 1 / 1 (100%)
Time: 00:00.080, Memory: 28.32 MB
There was 1 failure:
1) App\Provider\Tests\Contract\PactVerifyTest::testPactVerifyConsumer
Failed asserting that false is true.
/home/myname/Projects/pact-php-csv/example/provider/tests/Contract/PactVerifyTest.php:58
FAILURES!
Tests: 1, Assertions: 1, Failures: 1.
I think it should log an error message like:
Can't find plugin csv in /home/myname/.pact/plugins
Do you think so?Jordan Brooks
04/18/2023, 1:23 PMAdam Cox
04/28/2023, 2:18 PMws
and wss
connections, mostly to providers at the moment but it may be that we need it for consumers also. Currently our plugin just adds one "transport" to the catalogue: websockets
. But this means that when verifying contracts there is no way to tell the pact-standalone-verifier to use a wss
scheme when connecting to the provider server.
We noticed that the ProviderInfo
struct has a scheme
field which looks like it would be perfect for our use case but the pact-standalone-verifier does not expose this option. Looking at the source code here [1] it looks like it used to, but this is not listed in the docs a the top.
We considered having the plugin create two transports ws
and wss
but this then meant that the consumer would have to determine which transport to choose so that it is written into the contract. We weren't sure if this was correct as it doesn't really matter for the contract contents if the connection is secure or not. Also we wanted to avoid consumer users from having to create self-signed certs to create contracts unless they really wanted to test with the mock server over wss.
Guidance as to the intended approach would be most appreciated 🙂
Side, but related, note: in pact-consumer it looks like tls
is hard-coded to false [2]. Why is that? Has this not been implemented yet or are secure connections supposed to be solved a different way?
[1] https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_verifier_cli/src/main.rs#L673
[2] https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_consumer/src/mock_server/plugin_mock_server.rs#L64Adam Cox
05/09/2023, 1:28 PM<ws://localhost:9998/jsonrpc>
- specifically the /jsonrpc
bit
• Headers to send in the connection request
• Message payload encoding as text or binary
We are using synchronous message contracts to do the verification and we are trying to extend the plugin so that these metadata properties can be set, however we are struggling to find the code path that allows plugin config to be added to the contract files when a core matcher is being used.
Advice/guidance on how to achieve this would be greatly appreciatedAdam Cox
06/02/2023, 9:51 AM"request": { "id": 1 },
The configure interaction request receives a payload like this:
"request": Value { kind: Some(StructValue(Struct { fields: {"id": Value { kind: Some(NumberValue(1.0)) } } })) }
Now in the contract the the value to match against is 1.0
and not 1
. In the consumer test a message is sent to the mock server with the payload:
{
"id": 1
}
When the mock server receives this request we try to match against all interactions in the pact but we get a mismatch for this field as:
1.1) [$.id] Expected '0.0' to be equal to '0'
I have been trying to debug and fix this issue and it looks to me like the following is happening:
1. The pact framework is taking the consumer contract and converting it to a protobuf payload to send to the plugin
2. This process converted the id field to a Value:Kind:Number(&f64)
3. In the plugin we decode the protobuf payload using proto_value_to_json
(I think I took this directly from your protobuf plugin) and for a number Kind it runs: serde_json::json!(n)
4. serde is seeing the f64 and creating a Value::Number(Number::Float))
5. So now we have lost the information that the original number was an int and not a float and our comparison fails when we receive an int
It seems to me that serde has a good way of handling the different number types but the prost_types definition of Kind::NumberValue(f64),
is reducing the amount of information that can be conveyed to the plugin about a numeric field during the configure interaction request.
I had a search online around protobuf number types and it looked like different types of numbers are supported so I'm not understanding why prost_types treats all numbers as floats. I am not very familiar with protobuf at all though so I probably am just missing something.
In the mean time we are encouraging the users to define the contract as { "id": "matching(integer, 1)" }
but I think it should be possible for them to just specify the contract as { "id": 1 }
and have it work. This did work when we were using the core application/json matcher but I am assuming that is because the type information is not lost when passing the values around in rust.Adam Cox
06/14/2023, 1:51 PMAdam Cox
06/14/2023, 2:44 PM1) c9d8b50f42b5d1e7 - the following mismatches occurred:
1.1) [] Expected metadata key 'headers' to have value '{"sec-websocket-protocol":"json-rpc"}' but was '{"connection":"upgrade","host":"[::1]:64257","sec-websocket-key":"qtwa71ue1dhx8b0ffbiqyw==","sec-websocket-protocol":"json-rpc","sec-websocket-version":"13","upgrade":"websocket"}' - Expected '{"sec-websocket-protocol":"json-rpc"}' to be equal to '{"connection":"upgrade","host":"[::1]:64257","sec-websocket-key":"qtwa71ue1dhx8b0ffbiqyw==","sec-websocket-protocol":"json-rpc","sec-websocket-version":"13","upgrade":"websocket"}'
The contract specifies the "sec-websocket-protocol":"json-rpc"
header, but the request comes in with a lot of others. We only need the one header validated in the contract. The connection request we are establishing has the header and it has the correct value so this should pass. However as the contract doesn't contain all the other headers it fails.
I'd like to make the matching work like the header matching in HTTP contracts, however I want the headers in an object called headers and not on the root of the metadata object. This is because we are now trying to add query params as well and I'd like to keep the two separate.uglyog
Praveen Erode Mohanasundaram
07/14/2023, 2:15 PMPraveen Erode Mohanasundaram
07/14/2023, 2:15 PMPraveen Erode Mohanasundaram
07/14/2023, 2:19 PMRohit Krishnan
07/25/2023, 8:39 PMYousaf Nabi (pactflow.io)
Elena Doty
08/16/2023, 8:42 PM