Fix a potential connection leak on tzdata update #59
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes a potential connection leak on
Tzdata.ReleaseUpdater.poll_for_update/1
.In hackney_pool, connections won't be checked in until the response body was read or skipped by calling functions like
:hackney.body/1
or:hackney.skip_body/1
(this is expected behavior as of benoitc/hackney#160).Current implementation possibly cause the connection leak if
Tzdata.DataLoader.latest_file_size_by_get/1
(invoked byTzdata.ReleaseUpdater.poll_for_update/1
) returns the status code other than 200.Tzdata uses
:default
pool of hackney for HTTP request, so other applications using:default
pool can also be affected.Note
I suspected that #56 is maybe related this fix, since IANA will return
302
with "www.iana.org" (fixed by #51), and that is exactly the situation that connection leak will happen.