https://pact.io logo
Join Slack
Powered by
hey <#CLS16AVEE|> i'm facing this Mismatches mess...
# pactflow
g
hey #CLS16AVEE i'm facing this Mismatches message error after run the provider tests:
Copy code
Body:
$: Expected body type of 'application/json' but received 'text/html'

Header:
Content-Type: Mismatch with header 'Content-Type': Expected header 'Content-Type' to have value 'application/json' but was 'text/html'
where should I manage that? at service? at provider file?
is this issue related and still in progress? issue-575
m
The problem is your provider is responding with HTML and not json. The issue is with your provider or your test is wrong (E.g. is hitting the wrong endpoint)
g
I see, let me double check then, thanks!
👍 1
hey @Matt (pactflow.io / pact-js / pact-go) i have checked and i'm hitting the correct endpoint, the error is related to Mismatches I updated the service and consumer to send the request without Content-Type and Accept, it worked and I can run the consumer and then the publisher step! However the provider step is still failing for one of my three services that i have and is about the Content-Type which looks confusing because i'm not sending this header at all and in the consumer spec i'm not expecting for any header as well
looking at terminal i could see this:
Copy code
2023-03-20T19:18:33.500771Z  INFO ThreadId(12) pact_verifier::provider_client: Sending request HTTP Request ( method: POST, path: /dynamicApi, query: None, headers: Some({"Content-Type": ["application/json"], "Authorization": ["Bearer undefined"]}), body: Present(523 bytes) )
2023-03-20T19:18:34.129861Z  INFO ThreadId(12) pact_verifier::provider_client: Received response: HTTP Response ( status: 200, headers: Some({"connection": ["close"], "x-powered-by": ["Express"], "x-amz-version-id": ["12OAnMDcwjX61drz1pjWwYOPF4..klSN"], "via": ["1.1 <http://e8eec15d9551dd475d4c478f9fbb5f04.cloudfront.net|e8eec15d9551dd475d4c478f9fbb5f04.cloudfront.net> (CloudFront)"], "x-amz-cf-pop": ["IAD12-P3"], "accept-ranges": ["bytes"], "last-modified": ["Tue", "14 Feb 2023 20:52:17 GMT"], "x-amz-cf-id": ["Xjw15a5yV5gWhs_wHi8mGd67o4fbSCh4kzF5t1D-lJesk-aiymZ29g=="], "x-cache": ["Error from cloudfront"], "date": ["Mon", "20 Mar 2023 19:18:38 GMT"], "x-amz-server-side-encryption": ["AES256"], "server": ["AmazonS3"], "etag": ["\"f522e4542a43a286da7783b5f70d983f\""], "content-type": ["text/html"], "content-length": ["37937"]}), body: Present(37937 bytes, text/html) )
""x-cache": ["Error from cloudfront"]"
this Error from cloudfront might from pactflow somehow? @Matt (pactflow.io / pact-js / pact-go)
t
No, that means that Cloudfront has cached an S3 response error. I don’t know why it’s coming back as a 200 - I would guess some configuration error in the way cloudfront is set up on your provider, causing it to mis-report errors.
"Authorization": ["Bearer undefined"]
<-- this is very suspicious
My guess is that your test is not set up correctly, causing there to be no authentication token (perhaps this 
undefined
made it in to the contract during the consumer test)
confusing because i’m not sending this header at all
You are sending a content-type header, because http requires it if you have a body. Pact knows this, and will match on the content types. As Matt said above, you’re experiencing errors here because the content that is returned by your provider during the test is text/html (as you can see in your snippet).
g
"Authorization": ["Bearer undefined"]
<-- this is very suspicious
sorry but i don't know the reason for that, i'm sending the token at Auth header and i saw that but i couldn't figure out the reason! the confusing thing is that for those others services that i have works correctly and specially for this one don't Anyway i'll review each file and each test
My guess is that your test is not set up correctly, causing there to be no authentication token (perhaps this 
undefined
made it in to the contract during the consumer test)
if was the case i shouldn't see any FAIL message from pact, right? I mean after run the consumer tests i should at least see a warning or failed result here is the output after run the consumer tests:
Copy code
2023-03-22T17:59:01.165083Z  INFO tokio-runtime-worker pact_mock_server::hyper_server: Received request HTTP Request ( method: POST, path: /dynamicApi, query: None, headers: Some({"host": ["127.0.0.1:53884"], "content-length": ["523"], "content-type": ["application/json"], "accept": ["application/json", "text/plain", "*/*"], "accept-encoding": ["gzip", "compress", "deflate", "br"], "user-agent": ["axios/1.3.1"], "authorization": ["Bearer undefined"], "connection": ["close"]}), body: Present(523 bytes, application/json) )
2023-03-22T17:59:01.165192Z  INFO tokio-runtime-worker pact_matching: comparing to expected HTTP Request ( method: POST, path: /dynamicApi, query: None, headers: Some({"Content-Type": ["application/json"], "Authorization": ["Bearer undefined"]}), body: Present(523 bytes, application/json) )2023-03-22T17:59:01.166133Z  INFO tokio-runtime-worker pact_mock_server::hyper_server: Request matched, sending response HTTP Response ( status: 200, headers: Some({"Content-Type": ["application/json"]}), body: Present(3247 bytes, application/json) )2023-03-22T17:59:01.169841Z  WARN ThreadId(02) pact_models::pact: Note: Existing pact is an older specification version (V3), and will be upgraded
@Timothy Jones
You are sending a content-type header, because http requires it if you have a body. Pact knows this, and will match on the content types. As Matt said above, you’re experiencing errors here because the content that is returned by your provider during the test is text/html (as you can see in your snippet).
i get that but i'm not getting understanding the reason why is turning to text/html after run the provider tests.... here is my request at pactflow / expected response
t
Your provider is returning text/html, not pactflow. It is probably doing that because your consumer test has a broken auth header
☝️ 1
Can you share the test code that generated this interaction?
☝️ 1
g
sure @Timothy Jones you mean the pact file or the provider spec?!
t
The consumer spec please
The consumer test code that you used to generate the pact file
g
sure here is:
dynamicApi.spec.ts
t
Copy code
const token = process.env.ACCESS_TOKEN;
^ This might be undefined. In general, you shouldn’t rely on an environment variable during tests. More importantly, you shouldn’t write a real access token into the contract. Usually, you would do something like 
const token = "someToken"
and then have a state like 
"someToken is a valid token"
and stub out your authentication. Alternatively, you can use 
fromProviderState
to get the token from the provider state, and use a dummy one during the contract definition.
To be clear, that line might be undefined - and definitely was at the time you wrote the contract that you’re having trouble verifying.
g
i see, let me figure out another option then
@Timothy Jones I've update my consumer tests with a token valid just to check the results at pactflow and here is the result: even using a valid token i'm still facing the Mismatches error:
Copy code
Body:
- Expected body type of 'application/json' but received 'text/html'

Header:
- Content-Type: Mismatch with header 'Content-Type': Expected header 'Content-Type' to have value 'application/json' but was 'text/html'
as you can see below i've sent the token instead undefined
m
So PactFlow is just showing you what the provider test got. You’ll need to look at the logs of your provider test build to see why you are getting this 
text/html
. It seems like it’s returning an http 200 because there are no errors about the status (that seems concerning to me also) but it’s definitely getting back something that’s not JSON. Perhaps you could share your provider test? Are you running it against a live system or a local build?
g
sure, here is the provider spec
dynamicApi_spec_ts.ts
m
Thanks. A few things 1. You seem to be using a fixed environment. This will make supporting provider states difficult, as well as authorization. You will need to either hard code credentials that don’t expire into the consumer test, or I can suggest you consider using a 
requestFilter
to inject one a correct one at runtime (see Step 10 of https://github.com/pact-foundation/pact-workshop-js/) 2. You shouldn’t specify 
pactUrls
to a hard coded 
latest
. You should use consumer version selectors for this purpose. I would highly recommend running the above workshop and also consider the CI/CD workshop (see howtolearn 👇 )
s
Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops
m
Please share the output log file also
t
Also, it’s best not to hard code your pactBrokerToken (it should come from an environment variable), and it’s also not good to share it on slack - you may want to change it now.
👍 1
Putting your access token in the contract isn’t what I advised - you should follow the auth approach in the docs. Probably what is happening is that your auth token is not valid at the time of the verification.
The error you have looks like it comes from cloudfront - I would start there looking for the misconfiguration
g
I'll review and if necessary apply your thoughts, thanks! I do thing is something related to cloudfront as well @Timothy Jones but i'm not aware how to investigate that.... @Matt (pactflow.io / pact-js / pact-go) how can i grab or generate the output log?
t
That’s a question for your provider team
g
Actually in my company there is no provider team, so i don't know where to start to look this misconfiguration....probably backend team might know something
t
Yes, the team that’s responsible for the thing you’re trying to test
👍 2
m
If it’s 9.x.x of Pact, then it looks like it should be in 
./logs/pact.log
. If it’s 10.x.x or later please set the log level to 
DEBUG
and attach as a file here (please redact any sensitive info, such as credentials)
👍 1
Open in Slack
PreviousNext
Powered by