https://pact.io logo
Join Slack
Powered by
According to the doc here: <https://github.com/pac...
# protobufs
s
According to the doc here: https://github.com/pactflow/pact-protobuf-plugin?tab=readme-ov-file#verifying-grpc-error-responses-031 you can specify a matcher on metadata fields, but when I ran the test with pact-go, my pact file doesn't contain any matchers for the metadata value. When I read through the pact v4 spec, it doesn't look like you can specify matchers for metadata at all, but I could've missed it, it's a big doc 😅 Are matchers supported on metadata fields?
Copy code
"response": [
        {
          "contents": {
            "content": ""
          },
          "metadata": {
            "contentType": "application/protobuf;message=Feature",
            "grpc-message": "no feature was found at latitude:-1  longitude:-1",
            "grpc-status": "NOT_FOUND"
          }
        }
      ],
r
It definitely supports matching rules on metadata.
There is an example somewhere, I'll try find it
s
so it could be that it's pact-go strips it somehow? I'll look more into this
r
Hmm, it shouldn't be doing anything, but passing the JSON strait on through
s
if it's not too much to ask and if you have already set up the pact-plugins repo on your machine, could you please run the consumer-jvm example and share the resulting pact json file so I can compare with what pact-go generated? Could be user error on my side. If it'll take you more than 2 minutes, it's ok tho, I can take a look too. Thanks!
r
Copy code
{
  "consumer": {
    "name": "grpc-consumer-jvm"
  },
  "interactions": [
    {
      "comments": {
        "testname": "io.pact.example.grpc.consumer.PactConsumerTest.testMetadata(MockServer)"
      },
      "description": "validate token request",
      "interactionMarkup": {
        "markup": "```protobuf\nmessage ValidateTokenRequest {\n}\n```\n\n```protobuf\nmessage ValidateTokenResult {\n    bool ok = 1;\n}\n```\n",
        "markupType": "COMMON_MARK"
      },
      "key": "124feec5",
      "pending": false,
      "pluginConfiguration": {
        "protobuf": {
          "descriptorKey": "21e4eba65e4d1100ce2fb63b5e6b2c3e",
          "service": "Test/ValidateToken"
        }
      },
      "request": {
        "contents": {
          "content": ""
        },
        "matchingRules": {
          "metadata": {
            "Auth": {
              "combine": "AND",
              "matchers": [
                {
                  "match": "regex",
                  "regex": "[A-Z]{3}\\d+"
                }
              ]
            }
          }
        },
        "metadata": {
          "Auth": "AST00004",
          "contentType": "application/protobuf;message=ValidateTokenRequest"
        }
      },
      "response": [
        {
          "contents": {
            "content": "CAE=",
            "contentType": "application/protobuf; message=ValidateTokenResult",
            "contentTypeHint": "BINARY",
            "encoded": "base64"
          },
          "matchingRules": {
            "body": {
              "$.ok": {
                "combine": "AND",
                "matchers": [
                  {
                    "match": "boolean"
                  }
                ]
              }
            },
            "metadata": {
              "code": {
                "combine": "AND",
                "matchers": [
                  {
                    "match": "integer"
                  }
                ]
              }
            }
          },
          "metadata": {
            "code": "100",
            "contentType": "application/protobuf;message=ValidateTokenResult"
          }
        }
      ],
      "transport": "grpc",
      "type": "Synchronous/Messages"
    }
  ],
  "metadata": {
    "pact-jvm": {
      "version": "4.4.6"
    },
    "pactSpecification": {
      "version": "4.0"
    },
    "plugins": [
      {
        "configuration": {
          "21e4eba65e4d1100ce2fb63b5e6b2c3e": {
            "protoDescriptors": "Ct8BCg5tZXRhZGF0YS5wcm90bxIMbWV0YWRhdGF0ZXN0IhYKFFZhbGlkYXRlVG9rZW5SZXF1ZXN0IiUKE1ZhbGlkYXRlVG9rZW5SZXN1bHQSDgoCb2sYASABKAhSAm9rMmAKBFRlc3QSWAoNVmFsaWRhdGVUb2tlbhIiLm1ldGFkYXRhdGVzdC5WYWxpZGF0ZVRva2VuUmVxdWVzdBohLm1ldGFkYXRhdGVzdC5WYWxpZGF0ZVRva2VuUmVzdWx0IgBCFloUaW8ucGFjdC9tZXRhZGF0YXRlc3RiBnByb3RvMw==",
            "protoFile": "syntax = \"proto3\";\n\npackage metadatatest;\noption go_package = \"io.pact/metadatatest\";\n\nmessage ValidateTokenRequest {\n}\n\nmessage ValidateTokenResult {\n  bool ok = 1;\n}\n\nservice Test {\n  // This call requires the Auth header to be correctly set\n  rpc ValidateToken(ValidateTokenRequest) returns (ValidateTokenResult) {}\n}\n"
          }
        },
        "name": "protobuf",
        "version": "0.3.12"
      }
    ]
  },
  "provider": {
    "name": "validate-token-provider"
  }
}
superman 1
thankyou 2 1
s
thank you, I'll look into what's different in how pact-go processes it (or if I'm doing something wrong maybe)
nvm, the previous post (deleted) let me read through some more
Reproduced the issue inside pact-protobuf plugin itself: https://github.com/pactflow/pact-protobuf-plugin/pull/46 I'll experiment some more with it and try to walk through this with a debugger. Would appreciate any debugging suggestions
🙏 1
I've found this spot in the pact-reference that seems to populate metadata matching rules, but not sure yet where it's called, there are quite a lot of various message types between sync/async and v3/v4 and what not: https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_consumer/src/builders/sync_message_builder.rs#L463
r
I normally use the trace logs or the 
dbg!
macro for debugging. If you use the JetBrains IDEs (CLion or Rust Rover), then the debugger in the IDE will work. I've tested Rust Rover, it works ok.
👍 1
Looks like it might be a pact_consumer issue. I can see the values passed back from the plugin in the logs:
Copy code
metadata_rules: {"key": MatchingRules { rule: [MatchingRule { r#type: "type", values: None }] }}, metadata_generators: {} })
metadata_rules: {"grpc-message": MatchingRules { rule: [MatchingRule { r#type: "type", values: None }] }}, metadata_generators: {} }]
The issue is here: https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_consumer/src/builders/sync_message_builder.rs#L133 But that is for Rust tests, there must be another place with the same problem if it is happening in your Go tests.
🤔 1
s
Looks like it might be a pact_consumer issue. I can see the values passed back from the plugin in the logs:
yep, can confirm the same, plugin seems to respond with the correct interaction response with go tests too. Go is just passing values to/from ffi lib and is doing very minimal processing on its own it seems
Let me try a fixed pact consumer locally. I think I can just refer to a local path of the pact_consumer in my cargo.toml in the protobuf-plugin and that should work, right?
r
Yes, that should work
thankyou 2 1
I have created a failing unit in the pact_consumer project
Ok, found the same issue in the Pact FFI crate.
Are you going to try fix the pact_consumer one? Or do you need me to do it.
s
I can try to fix the pact_consumer in an hour or two, will send a PR. Can you pls point me to the pact ffi issue (so I can learn more)?
r
It doesn't look at the metadata matching rules at all
s
interesting, so it's separate implementations for rust, jvm and ffi?
r
Yes, unfortunately
👍 1
s
https://github.com/pact-foundation/pact-reference/pull/384 pls let me know if you want commits squashed beforehand, or if we can squash them during merge
👌 1
learning how to write rust using copy paste and copilot 😄
I'm not sure if there are any linter/formatter/code-quality tasks I should run to make sure PR is ok? the docs mention cargo build and that works; also tests that I wrote work too
y
Thanks for the change @Stanislav Vodetskyi, really appreciate it, and it’s nice seeing the journey too! > learning how to write rust using copy paste and copilot 😄 😅 I feel you man! It has been a bit of help whilst polyglotting. > pls let me know if you want commits squashed beforehand, or if we can squash them during merge I think it might be better squashing prior as I think you lose some attribution to the change if the merger squashes. I might not be quite correct but I taught to try and tell others providing contributions to squash first. > I’m not sure if there are any linter/formatter/code-quality tasks I should run to make sure PR is ok? the docs mention cargo build and that works; also tests that I wrote work too Should get picked up in the existing test suite and with the additions you’ve included. I don’t think there is any standardised formatting rules existing in the repo that you can apply, and I think modern day formatting will change the files alot, which I don’t believe Ron is in favour of, as it makes the commit history messy when looking at why a line was changed. BTW - How are you finding the plugin stuff in general? Are you still at a POC stage, or have you got it reasonably well embedded at the moment?
s
I think it might be better squashing prior as I think you lose some attribution to the change if the merger squashes. I might not be quite correct but I taught to try and tell others providing contributions to squash first.
ok, I'll squash them on my side 🙂
BTW - How are you finding the plugin stuff in general? Are you still at a POC stage, or have you got it reasonably well embedded at the moment?
we've started onboarding more projects, but it's still an early phase. It's been mostly a smooth journey so far, couple of bugs here and there but overall easy to onboard! 👍 I can share some findings and places we had to work around in a different thread after we finish onboarding more projects
squashed
I've also updated the PR in protobuf-plugin to actually verify the metadata rules programmatically vs just looking at the pact file
7 Views
Open in Slack
PreviousNext
Powered by