Hi, We have some provider tetsts and lately they ...
# pactflow
r
Hi, We have some provider tetsts and lately they fail with always the same error:
Copy code
ProviderPactTest.initializationError
au.com.dius.pact.core.pactbroker.RequestFailedException: Request to path 'https://<orga>.<http://pactflow.io/pacts/provider/<provider/for-verification|pactflow.io/pacts/provider/<provider/for-verification>' failed with response 500
So I have to run them 2-3 times to get them working. any idea what the problem is?
m
can you please DM me with your account URL (e.g. the <orga> bit in your URL above)?
i
Thanks @Ruth we have been monitoring this in our logs, and do see a performance degradation but it is in a complex area so debugging this is challenging, that said, would you mind opening a support case while we investigate on our side
(if you have already, please ignore šŸ™‚)
m
Ruth created it last night, it’s 00667883
thankyou 1
r
Hi, any news? We have really big problems getting pacts to verify now I haven't managed to get anything so far today... it also seems to just be this one provider that has problems?
i
Hey @Ruth we will look into this, please give us a few days, its very odd that it impacts just that provider, but it gives us narrow scope to look into this
šŸ‘ 1
r
is there any pact-jvm classes we can turn on debug logs for to give more information?
p
looks like it is trying to fetch a lot of data, from the logs I see that,
"includeWipPactsSince":"2024-01-01"
is there a way to change this date to more recent, one
r
I do not understand why I need that date at all, I would like to have a relative time frame instead of a fixed date. But it should not fetch so much data as it only gets the poacts that have not yet been verified, right?
p
this option is not mandatory, I think
maybe you can simply remove the line
r
it did not work without it
p
I will ask my colleagues, but for now may be you can use a recent date, we do have a support ticket on this, so I will update there once we have more info
y
You can use the HAL explorer to view the pacts that would be retrieved for a provider https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/provider-pacts-for-verification.markdown You can configure the
includeWipPactsSince
date to see if this reduces the quantity returned. You will be able to see which pacts are being returned. It would be good to see if these additional pacts which are being retrieved by including WIP pacts, as these follow a specific criteria. By working out which pacts are being picked up and why they aren't verified would be a good start in reducing the amount of pacts that are returned
A ā€œwork in progressā€ pact is a pact that:
1. is the latest for its branch (or tags)
2. does not have a successful verification result from the current provider branch (or tags) - that is, the pact is in ā€œpendingā€ state.
3. was not explicitly specified in the consumer version selectors
These has been some discussion about simplifying the wip workflow https://github.com/pact-foundation/pact_broker/discussions/640 with a current tl;dr of deleting branches from your pact broker when removed in your SCM https://docs.pact.io/blog/2024/02/21/deleting-branches-automatically
šŸ’Æ 1
I do not understand why I need that date at all
That is the way it is coded
I would like to have a relative time frame instead of a fixed date.
You can set this in your code, rather than hard coding a set, set it to be a date offset from the current time the test is run
But it should not fetch so much data as it only gets the poacts that have not yet been verified, right?
Correct, see selection criteria above. Seeing which pacts are selected, and why they aren't verified for this provider would be a good start
it did not work without it
with regards to removing
includeWipPactsSince
- how exactly did this not work? Still too many pacts, or failed to compile?
r
with regards to removing
includeWipPactsSince
- how exactly did this not work?
When I initially tried it without a date I got the error message that a date has to be set. But that does not happen anymore, so maybe that was a red hering when I initially tried out that feature
You can set this in your code, rather than hard coding a set, set it to be a date offset from the current time the test is run
As it is java annotations I use I could not create a relative date there as it is not static. but I could add a gradle property and then calculate it. but if it actually works without it then I prefer that anywys šŸ™‚
with a current tl;dr of deleting branches from your pact broker when removed in your SCM
I read in the discussion
The API deletes the branches asynchronously, and doesn't actually delete the application versions or pacts - it just deletes the branches. This means that even though the pacts still exist, they won't show up in the "latest pact for each branch" verification response.
So does that mean that there is a pact but is "looks" like it is done without branch information?
y
morning. ah sorry didn’t realise with regards to it being in an annotation. great that it is working without the date set it as it should be. red herring indeed but they are easy to come across when diagnosing. correct the pact versions that were once associated with that branch remain ( as the same version may be promoted to another branch/env and its useful to know if you’ve previously verified those pact contents
r
have you changed anything on your end? Because so far today I did not experience any problem and I did not change any code yet šŸ˜…
y
šŸ˜… most peculiar. I don’t believe so but will check with team. I’m behind them timezone wise so lots of things happen whilst I am asleep!
can confirm nothing changed on our side. is this testing without wip pacts enabled?
m
Hi Ruth, I’ve checked the open ticket. I don’t believe anything has changed on our end today but will follow up with the engineering folks tomorrow
r
Could it have something to do with the work load? Obviously over the weekend not much has happened and so the verification link was not requested a lot.
m
Certainly the volume of data that was being queried in the call to the
/..../for-verification
endpoint was contributing to this, and additional requests that overlapped with this table would cause locks etc.
šŸ‘ 1