Why is this only relevant in this test? I would expect we'd need to handle this problem in the product as well.

How do we know the transport exception is due to the network and not how the request is formulated?

Why is this only relevant in this test?

The issue linked has more info. This is the only test that's failing intermittently due to the CRL validation check timing out for our test site. This test enables that TransportOptions EnableCertificateRevocationListCheck setting. For others, this setting is off by default (or use "real" sites).

I would expect we'd need to handle this problem in the product as well.

Ability to deal with transient network failures is handled in the product, via the RetryPolicy. This test is directly calling the transport layer. See the pipeline being used in the tests:

How do we know the transport exception is due to the network and not how the request is formulated?

Because it is intermittent, at 95%+ success rate, and we know the error. The CRL validation check is hitting a transient timeout. If there was an issue with the request, it would be more determinsitic and we'd see different error behavior.

/azp run cpp - core - ci

@danieljurek CI pipeline runs keep getting canceled after 45 minutes. Can you please help with this? Otherwise green runs aren't showing up as passing.

The win2022 image has been deleted at that version. we'll have to roll forward to the latest image which has the problems detailed here: #5483 ... I'm working on removing unneeded packages based on the mitigation described here: actions/runner-images#9701