Shorten default timeout of individual calls to backend #657
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR aims to shorten the default timeout for individual backend calls and safely dispose of the HttpClientTransport.
- Introduces a new check for TaskCanceledException with an InnerException of TimeoutException in the fail-over logic.
- Updates AzureAppConfigurationOptions to implement IDisposable and dispose of the HttpClientTransport instance.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Microsoft.Extensions.Configuration.AzureAppConfiguration/AzureAppConfigurationProvider.cs | Adds a check for TaskCanceledException to improve timeout fail-over handling. |
| src/Microsoft.Extensions.Configuration.AzureAppConfiguration/AzureAppConfigurationOptions.cs | Updates the class to implement IDisposable and disposes of HttpClientTransport to avoid resource leaks. |
…etProvider into ajusupovic/shorten-default-timeout
amerjusupovic
force-pushed
the
ajusupovic/shorten-default-timeout
branch
from
0e77499 to
831adb2
Compare
…etProvider into ajusupovic/shorten-default-timeout
| @@ -18,10 +20,11 @@ namespace Microsoft.Extensions.Configuration.AzureAppConfiguration | |||
| /// Options used to configure the behavior of an Azure App Configuration provider. | |||
| /// If neither <see cref="Select"/> nor <see cref="SelectSnapshot"/> is ever called, all key-values with no label are included in the configuration provider. | |||
| /// </summary> | |||
| public class AzureAppConfigurationOptions | |||
| public class AzureAppConfigurationOptions : IDisposable | |||
There was a problem hiding this comment.
When is dispose called on this in a customer app?
There was a problem hiding this comment.
Missed this, looks like we could call _options.Dispose in AzureAppConfigurationProvider.Dispose?
There was a problem hiding this comment.
Whoever creates a disposable object should be the one to dispose it. In our case AzureAppConfigurationOptions is created internally and doesn't make sense to be disposed where it's created.
So I'm not sure we should be doing it this way at all. I'm leaning towards us doing this via a policy instead of passing an HttpClient.
This is a redo of a PR that was previously merged and reverted: #620
This PR adds a way to dispose of the
HttpClientTransportclass that was added, but otherwise the change is intended to be the same.