https://pact.io logo
Join Slack
Powered by
Hi, this is likely user error somehow, but I don't...
# general
d
Hi, this is likely user error somehow, but I don't know where. We have a pact that expects a response with content type 
application/jwt; charset=UTF-8
the pact contains an example response body (which has been encoded into base64 by the pact framework) and also a matching rule. When I run the provider side test it fails with a message like 
1.1) body: / Actual body [application/jwt, 903 bytes, starting with 65794a30655841694f694a4b563151694c434a68624763694f694a46557a4931] is not equal to the expected body [application/jwt, 1248 bytes, starting with 5a586c4b4d47565951576c506155704c566a465261557844536d686952324e70]
This is surprising for a couple of reasons: 1. The expected bytes value is the base64 encoded version of the body - it should have been base64 decoded before being compared? 2. As there is a matcher rule I would not expect the example body to be used at all - or do matchers not work with non-JSON/XML bodies?
I've tried setting 
pact.content_type.override.application.jwt=text
which does the comparison as a string, but it still doesn't use the string matching rule in the pact.
I think it could be that my pact file isn't set up correctly so the matches aren't being found.
So, in case it helps anyone else I needed to: 1. Fix my pact file to target the regex matcher at 
body
and 
$
2. Add 
System.setProperty("pact.content_type.override.application/jwt", "text");
to my tests (note that this not 
pact.content_type.override.application.jwt
as in the docs here: https://docs.pact.io/implementation_guides/jvm/provider/junit#overriding-the-handling-of-a-body-data-type)
🙏 2
m
Ah, good find. Looks like we need to update the docs
@rholshausen does this look correct?
r
LGTM
👍 1
m
d
Thanks for updating the docs so quickly. FWIW on the consumer side it seems that both 
application.jwt
and 
application/jwt
work.
m
oh, interesting. Thanks for sharing - much appreciated!
Open in Slack
PreviousNext
Powered by