https://pact.io logo
Join Slack
Powered by
Hi folks, I've noticed a weird behavior in one of ...
# pact-broker
s
Hi folks, I've noticed a weird behavior in one of our repos, where we publish an identical pact, but still trigger a webhook:
Copy code
Events detected: contract_published (pact content is the same as previous versions with tags  and no new tags were applied), contract_requiring_verification_published (pact content is the same as previous versions with tags  and no new tags were applied)
Is there a way to see what was the logic that the broker used to decide that 
contract_requiring_verification_published
event happens? What should I look for in the logs?
m
it’s possible a version of a provider needs to verify the pact, even though one has verified it (such as the main branch build). In the logs of the webhook, it should have a JSON blob at the top of it that shows the actual reason (e.g. because it’s deployed to an environment or is the main branch)
s
the logs of the webhook say that it's deployed in the environment and that's why it's verified. What doesn't make sense is that the contract hasn't changed in months, yet the webhook is still triggered. Like if I publish the contract that's exactly the same as before, it shouldn't trigger a webhook, right?
m
My guess is that version never verified the contract. Even though you may have webhooks setup to verify changes, if that version never verified it it will continually show up in the triggered webhooks until it does
It’s a bit confusion, I’ll admit, but the intent makes sense once you think about it. Most people (understandably) don’t checkout specific commit versions when the webhook triggers, and just run the latest of the main branch to verify the pact that is changed
My guess is that version never verified the contract.
or rather, if this isn’t the case, there is a bug somewhere
s
That doesn't seem to be the case, it is being verified successfully. The consumer in question is weird, though, so I'm wondering if this could lead to any interesting behavior. We have two repos where we experimented with using pact for self-testing. Each has a consumer test between a 
fake-consumer
and itself. The test isn't changing in months, so the contract should be the same between every push. But when we publish this contract, we use the provider version for the 
fake-consumer
so in the broker we basically have two separate versions for 
fake-consumer
published against different providers from different repos. And occasionally such publish triggers a webhook. Sometimes it doesn't though. But the contract is the same. Idk if the above makes sense 😄
I gotta run now, but will come back to this tomorrow and see if I can track a specific version verification history, like if it was published, was it considered verified right away, and if not, at which point it becomes verified
👍 1
I might be missing a broken verification step somewhere, which I hope is the culprit
👍 1
m
Of course, no worries - have a great evening 🙂
s
but do I understand correctly, that if I publish a new consumer version where the contract contents itself hasn't changed, the provider should be considered verified automatically?
I'm wondering if there's a race condition somewhere, where we publish consumer version X and provider version X at roughly the same time (cause they're in the same repo)? But it should still be ok, since the contents of the pact hasn't changed
m
> but do I understand correctly, that if I publish a new consumer version where the contract contents itself hasn’t changed, the provider should be considered verified automatically? yes, generally
if v1 of a provider has verified pact for consumer v1 with hash abc-123, if consumer v2 publishes a pact with the same contents, and v1 of the provider has already verified pact with hash abc-123, then it’s considered pre-verified
👍 1
(the pact file itself is versioned internally to the broker and separately from the consumer version. There are relationships to the consumer and provider versions to the pact version and verification results to make this determination)
s
what's really confusing is this message:
Copy code
contract_requiring_verification_published (pact content is the same as previous versions with tags  and no new tags were applied)
which says that contract requiring verification published, but pact content is the same as previous version. Is this normal/expected?
ok, I've figured out what's happening, and it indeed is the result of us using this "fake" consumer. Let me try to summarize
• there are two services - service-a and service-b; • each has a "self-test" between a "fake-consumer" and itself • service-a builds, a contract between 
fake-consumer
version 
a1
and 
service-a
is published. 
a1
is the latest version of a fake consumer on 
master
as far as pact-broker is concerned • service-b builds, a new version of 
fake-consumer
is published - 
b1
, which does not have a contract with 
service-a
, only with 
service-b
. • at this point if you hit the 
pacts/provider/SERVICE-A/for-verification
the broker returns an empty list, saying there are no pacts to verify - because the latest version of the 
fake-consumer
does not have a contract with 
service-a
. • now 
service-a
builds and runs a provider test; it doesn't find any contracts for verification because of the above • now 
service-a
publishes it's 
fake-consumer
version 
a2
which at this point is considered a new contract, triggering a webhook. • the issue is that 
a2
is not materially different from 
a1
, but because there was a 
b1
between them, it's considered new I guess. I was able to verify the behavior of 
/for-verification
endpoint by publishing a new version of 
fake-consumer
and checking whether 
service-a
or 
service-b
has pacts for verification. Once I pushed 
a2
manually, it triggered a webhook, even though there was an older version with an identical contract. So all in all, while this is something that can be fixed on the broker side, it is an edge case that stems from us using an unconventional approach. This will still happen if the team deletes a contract against a provider in version 2 and the reverts it in version 3, but that's probably very rare. I'm going to try to change self-tests from 
fake-consumer
to using the service name itself like 
service-a
and this should not lead to any webhooks anymore.
thankyou 1
m
Interesting - thanks for sharing. I need to wrap my head around it a bit further, but does seem like an edge case has been discovered and if I understand correctly, this isn’t the intent of that trigger
s
yeah, I don't think this is something urgent that needs fixing really, just an interesting edge case.
👍 1
looking at this made me notice that if you explicitly use ProviderVerifier.verify in pact-go (presumably the same in other languages), it will verify the pact even if it was pre-verified. I wonder if there's a way to tell your provider verifier code to skip pre-verified pacts; and I'm also not sure if I want to 🙂
2 Views
Open in Slack
PreviousNext
Powered by