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.
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
Test
isopen
onresponse_stream
#470Test
isopen
onresponse_stream
#470Changes from all commits
f676525
d6aeacc
6457586
8aa2679
29886a7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do different backends have different behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They really shouldn't. I think this all comes the fact that
HTTPBackend
returns aBase.BufferStream
by default whileDownloadsBackend
returns anIOBuffer
by default. For this PR I'm just recording the current behaviour and avoiding changing it because as we know closing/not closing a file can be a breaking behaviourThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to address these inconsistencies with #384
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, i think the changes here would benefit from a comment explaining that they are testing the current behaviour and also linking to the issue you intend to open about possibly changing this behaviour (at first i thought we were testing we had "buggy" behaviour, which seemed an odd thing to test, but now i understand)
The changes themselves all LGTM, i was just struggling to follow what it is that these tests are documenting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's expected to be
test_broken
above, but to work here -- why is that?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the reason for the difference in behaviour. Calling
read_body
may or may not close theIO
:AWS.jl/src/utilities/downloads_backend.jl
Lines 35 to 39 in 1722aa5
Whether this function is called is dependent on a couple of factors:
AWS.jl/src/utilities/downloads_backend.jl
Lines 70 to 74 in 1722aa5