[BUG] Azure.Core.ResponseOfT contains disposable Response
See original GitHub issueDescribe the bug
Response<T>
contains a disposable Response property. There is no way to dispose of the inner Response object. This is a memory leak and will cause additional overhead for garbage collection.
Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
- Bug Description Added
- Repro Steps Added
- Setup information Added
Issue Analytics
- State:
- Created 4 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Listener for Azure function was unable to start error while ...
I have one Azure function app and I am trying to run that locally but getting the below error. I have the storage...
Read more >Response Class (Azure) - Azure for .NET Developers
Represents the HTTP response from the service. ... Core v1.34.0 ... Indicates whether the status code of the returned response is considered an...
Read more >Azure.Core Namespace - Azure for .NET Developers
Explore all classes and interfaces of the Azure.Core ... Contains names of commonly used headers. ... Controls how error response content should be...
Read more >Azure Core shared client library for .NET
Core (and so Azure SDK libraries using Azure.Core) include: Configuring service clients, e.g. configuring retries, logging ( ClientOptions ).
Read more >Azure Core shared client library for Python
Azure core provides shared exceptions and modules for Python SDK client libraries. ... message is the HTTP response error message (optional).
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
My issues with this is it is dependent on a implementation detail, and not the contract. If someone changes that implementation in the future then this will be broken. There is also no way for users to know if they need to dispose of the inner stream or not to dispose of it.
What scenario requires supporting stream? Would users actually get better use out of always having a buffered Memory object?
We are controlling the clients and the pipeline and wouldn’t return Response<T> that has a network stream in it.