Hi, We are encountering issues 403 error related to publishing pact contract with Pactflow broker. Please find the details below. Could someone help us fix these 403 errors happening suddenly?

<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

what’s your tenant?

Just sent you our domain 🙂

Thanks Jas!

Hi @Matt (pactflow.io / pact-js / pact-go) - we're having the same issue, have been since last week.

We are still investigating the 403 errors and working to a solution. The issue is linked to GitHub Actions runners, so one short term option is to retry the failed step. We will update our status page once we have a more concrete update

FYI https://swagger.status.smartbear.com/incidents/wv558999lmtv The issue appears to be that our WAF (AWS) is blocking certain GitHub addresses on IP reputation.

Can I ask if there's been any progress on this? We're still hitting the same issue and it's affecting our build pipelines.

We are in a discussion with AWS, and still monitoring. The monitoring is indicating that the incidence rate has decreased, but is not yet back to normal.

Yes, we've had to throttle back our workflows quite heavily to reduce the affect. I'd really welcome the heads-up once it's resolved so I can return them to normal.

The issue is actually due to the public IPs used by the GitHub Runners having had a significant drop in reputation lately. Our WAF is blocking these requests at the edge (hence the 403 by CloudFront) based on the AWS managed IP reputation list. Unfortunately, no amount of retrying on the same runner will help. As best I can tell, you would have to retry the workflow and hope it gets allocated to a runner with a more reputable public IP. It's not ideal, but the number of disreputable IPs used by GitHub Runners seems to have decreased (at least, based on the monitoring I'm seeing).

Thanks Joshua, that's useful to know. Worrying, but useful! 😄 - it might mean that we look at self-hosted runners, which might improve the IP reputation issue, but I'll feedback.

Absolutely, if you can use self hosted runners, that would avoid the issue. You can also switch to the

large

variants of the runners or the macOS runners (they both use different CIDRs, and I guess due to their cost, are not abused as much).

Definitely! Though in fairness, we run that as part of a larger gradle task, so we'd probably use it on the whole. Gradle does love it's memory!

Thanks Josh and my apologies for this Graham - FWIW we’re also impacted (i.e. we use both GitHub and PactFlow, of course!) Anecdotally, we’ve seen some recent occurrences of bot activity on some of our github repositories, and with AI making it much easier to create large-scale attacks, I suspect that might explain the problem. GitHub themselves don’t recommend a blanket whitelist on their IPs, so that tells you something.

It's all important food for thought, thanks! And I always preferred Jenkins in the first place... 😄

This is the very discussion we are having internally, unfortunately, the IP address range is very large