-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve RequestsFetcher cleanup mechanisms #1303
Comments
I think fetch() being a CM might make sense (if it makes the client code nicer) but I don't believe it makes it any easier to handle cleanup... The only resource (that requires handling) in RequestsFetcher is the requests.Response: this is tricky because we return a generator function that owns the Response but otherwise I think there's nothing that requires attention.
|
Reviving this issue after having a look at requests_fetcher.py: @contextmanager
def fetch(self, url, required_length):
...
try:
response.raise_for_status()
yield self._chunks(response, required_length)
except requests.HTTPError as e:
status = e.response.status_code
raise exceptions.FetcherHTTPError(str(e), status)
finally:
response.close() download.py:
But this also means adding a requirement to |
@sechkova do you think this is still an active issue -- I think moving the download methods into Fetcher have solved the issues around this? I don't see our code having trouble with unclosed things currently |
Yeah, with |
Description or feature request:
Implement
RequestsFetcher
as a context manager and/or provide public cleanup method to be called by its users (for ex.fetcher.close()
)Current behavior:
RequestsFetcher
internlly tracks all exit paths to release allocated resources which is error prone.Expected behavior:
Reliably release all resources allocated by
RequestsFetcher
.The text was updated successfully, but these errors were encountered: