Describe the bug
Several OAuth tests occasionally fail on the windows-latest legs of Build and Test.
If that occurs, the GetAuthServerMetadataAsync method gets a TaskCancelledException
during a slow TLS handshake using the in-memory duplex pipe, ClientOAuthProvider wraps
that into the "Failed to find .well-known/..." message, and assertion expectations
about that message fail on the injected text – that is, the error manifests itself as
a confusing assertion failure instead of a timeout.
It appears to be similar to #1701 from the OAuth side of things. #1702 increased
the server/discover probe timeout in the in-memory tests, but the OAuth metadata
path has a similar timeout which was not added and is still failing after that merge.
Tests affected so far:
OAuth.AuthTests.CannotAuthenticate_WithInvalidClientMetadataDocumentOAuth.DcrFailureTests.DcrRejection_PropagatesToConsumer_WithStatusBodyAndSentParametersClientConformanceTests.RunConformanceTest(scenario: "auth/offline-access-scope")
To Reproduce
Intermittent, not deterministic reproduction possible. It is reproduced by running Build and Tests
of windows-latest leg multiple times.
The following two incidents are on August 9, right after merging PR #1702, for two consecutive
commits of the same branch which are identical but different in comments and tests:
a9f02522 - windows-latest, Debug - job - auth/offline-access-scopee07f4999 - windows-latest, Release - [job](https://
Expected behavior
Tests need to be deterministic. In case the timeout happens during fetching of the metadata, the issue should be thrown as a timeout and not as an assertion failure on an error message that’s not related to it at all.
Logs
From the e07f4999 Release run
Describe the bug
Several OAuth tests occasionally fail on the
windows-latestlegs of Build and Test.If that occurs, the
GetAuthServerMetadataAsyncmethod gets aTaskCancelledExceptionduring a slow TLS handshake using the in-memory duplex pipe,
ClientOAuthProviderwrapsthat into the "Failed to find .well-known/..." message, and assertion expectations
about that message fail on the injected text – that is, the error manifests itself as
a confusing assertion failure instead of a timeout.
It appears to be similar to #1701 from the OAuth side of things. #1702 increased
the
server/discoverprobe timeout in the in-memory tests, but the OAuth metadatapath has a similar timeout which was not added and is still failing after that merge.
Tests affected so far:
OAuth.AuthTests.CannotAuthenticate_WithInvalidClientMetadataDocumentOAuth.DcrFailureTests.DcrRejection_PropagatesToConsumer_WithStatusBodyAndSentParametersClientConformanceTests.RunConformanceTest(scenario: "auth/offline-access-scope")To Reproduce
Intermittent, not deterministic reproduction possible. It is reproduced by running Build and Tests
of
windows-latestleg multiple times.The following two incidents are on August 9, right after merging PR #1702, for two consecutive
commits of the same branch which are identical but different in comments and tests:
a9f02522- windows-latest, Debug - job -auth/offline-access-scopee07f4999- windows-latest, Release - [job](https://Expected behavior
Tests need to be deterministic. In case the timeout happens during fetching of the metadata, the issue should be thrown as a timeout and not as an assertion failure on an error message that’s not related to it at all.
Logs
From the
e07f4999Release run