-
Notifications
You must be signed in to change notification settings - Fork 62
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
DownloadsBackend inconsistently closes streams #471
Comments
Related to #433 |
Just to add another ref, I think this is case 2 from #396 (comment) |
384: Use `AWS.Response` to handle streaming/raw/parsing r=omus a=omus The idea is to use a struct in AWS.jl that can be used to handle the automatic parsing that is currently used to turn XML/JSON into a dict while also giving the option of accessing the raw output as a string or stream without all the keywords currently needed to be specified. Depends on: - #457 Related: - #346 - #348 - #438 Closes: - #224 - #433 - #468 (when using `use_response_type` the passed in I/O is not closed) - #471 - #433 Update: The tests in this PR run using the deprecated behaviour. Mainly I did that here to prove this change is non-breaking. For the updated tests see #458 Co-authored-by: Curtis Vogt <[email protected]>
As of AWS.jl 1.63.0 (#384) streams are no longer closed when using the feature When not enabling the |
The following test case is from #470:
Note how when using a non-
IOBuffer
and not using the"return_stream"
parameter that the I/O stream is closed but in all other cases it leaves the stream open. This inconsistency should not be present.Additionally, most likely the behaviour of the HTTPBackend and the DownloadsBackend should made to be consistent.
The text was updated successfully, but these errors were encountered: