Before starting: the egress network policy itself is fine. Just keep retrying the same build-config (without any change), will eventually result in a success.

For context, coreos-cincinnati-stub contains a build-config to build a Rust application from github. The service itself is still a work-in-progress while we iron out the details of the auto-update system for fedora-coreos.

Initially, the "coreos-cincinnati" project was egress-unconstrained, and builds were fine.
Since the introduction of egress network policies on the namespace, I'm seeing a 50% rate of build jobs just getting stuck while trying to access "crates.io", "github.com", and "static.crates.io". On an interesting note, just restarting the build under the exact same input conditions will randomly result in a success, eventually.

The symptoms are a bit vague and I cannot further self-debug due to cluster RBAC policies. The application builder (cargo) is not reporting any name resolution errors, transport error or HTTP timeouts. Other earlier commands in the build-config (e.g. dnf install) can access the Internet.

It looks like something is misbehaving at the network or egress-policy level, resulting in networking which is fine on the surface but stalling HTTPS flows to certain destinations.

As egress policies are defined by DNS names and most of those endpoints are behind CDNs, I wonder if there may be an underlying de-sync in name/IPs whitelist due to rapidly changing DNS entries.