Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

Handle case where ky responses have no body with a getter for a ReadableStream #1224

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

pcowgill
Copy link
Contributor

Closes https://github.com/ipfs/js-ipfs-http-client/issues/1215

@hugomrdias @alanshaw Let me know what you think! The tests are passing, I added a new test case, and I've run the lint script.

@pcowgill pcowgill changed the title Handle no response body with getter for ReadableStream case in ky requests Handle case where ky requests have no response body with a getter for a ReadableStream Jan 22, 2020
@pcowgill pcowgill changed the title Handle case where ky requests have no response body with a getter for a ReadableStream Handle case where ky responses have no body with a getter for a ReadableStream Jan 22, 2020
@pcowgill
Copy link
Contributor Author

The basic approach Hugo and I discussed for this PR was to pass the entire ky response to the helper lib that converts the response to an async iterable rather than just passing the Response.body and hoping that part is enough.

Copy link
Collaborator

@achingbrain achingbrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR, it mostly looks good, a few changes needed mentioned in the comments.

src/lib/stream-to-async-iterable.js Show resolved Hide resolved
src/add/index.js Outdated
@@ -16,21 +16,36 @@ module.exports = configure(({ ky }) => {
if (options.chunker) searchParams.set('chunker', options.chunker)
if (options.cidVersion) searchParams.set('cid-version', options.cidVersion)
if (options.cidBase) searchParams.set('cid-base', options.cidBase)
if (options.enableShardingExperiment != null) searchParams.set('enable-sharding-experiment', options.enableShardingExperiment)
if (options.enableShardingExperiment != null) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were these changes necessary? I personally like curly brackets around if statement bodies, even one liners, but this has made everything inconsistent and is outside the scope of the intended change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they weren't necessary. They happened due to the default code styling settings I have globally in VS Code. If this style is important and gates PR merging, though, we should modify the linter settings to throw a warning or an error with this style. Ideally, we would get aegir lint --fix to automatically resolve such warnings/errors too, which may happen out of the box when we enable the warning. I'll open an issue for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just opened the issue #1225

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've disabled the Prettier and JavaScript Standard Style extensions for this workspace locally in VS Code so that automatic linting changes won't make it into a PR against this repo next time, but I still think the linting settings change is worth making to make it simpler for others to make PRs in the future.

src/dht/put.js Outdated Show resolved Hide resolved
@pcowgill
Copy link
Contributor Author

Thanks for this PR, it mostly looks good, a few changes needed mentioned in the comments.

@achingbrain Thanks for the quick review! I'll work on addressing the comments now.

// An env where res.body getter for ReadableStream with getReader
// is not supported, for example in React Native
if (!body) {
if (res.arrayBuffer) {
Copy link
Contributor Author

@pcowgill pcowgill Jan 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@achingbrain @hugomrdias Do we want to console.log anything in this case, like "falling back to a hackier approach since the fetch being used here doesn't implement the streams spec"?

src/add-from-url.js Outdated Show resolved Hide resolved
src/add/index.js Outdated Show resolved Hide resolved
src/add/index.js Outdated
@@ -52,7 +52,7 @@ module.exports = configure(({ ky }) => {
}
})

function toCoreInterface ({ name, hash, size, mode, mtime }) {
function toCoreInterface({ name, hash, size, mode, mtime }) {
Copy link
Contributor Author

@pcowgill pcowgill Jan 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@achingbrain The aegir linter also could use a rule for this

@pcowgill
Copy link
Contributor Author

@achingbrain Okay, I think I've addressed all of your comments! Thanks again for the quick review. Could you please give this another review when you have a moment?

I reverted all of the style changes manually, although it retrospect it may have been faster to configure some local workspace settings to match the styling conventions of this project. Longer term I think this would be a nice improvement to make.

@pcowgill
Copy link
Contributor Author

Yikes, it looks like there are a lot of merge conflicts now that another PR was merged. I'll work on resolving them.

@pcowgill
Copy link
Contributor Author

Looks like it was this PR #1183

@pcowgill
Copy link
Contributor Author

@achingbrain @hugomrdias I don't think getting the conflicts resolved gates an interim PR review, though, in case you have time. Thanks!

@pcowgill
Copy link
Contributor Author

@achingbrain I fixed the merge conflicts. We need to decide how we want to handle this issue - alanshaw/stream-to-it#3 (comment) - before merging this, now that one of the previously modified files, lib/stream-to-async-iterable, was extracted into this shared package

@pcowgill
Copy link
Contributor Author

Some tests are failing with the new logic introduced in this PR, like this one:

  1) .files (the MFS API part)
       .add pins by default:
     Error: Neither Response.body nor Response.arrayBuffer is defined

Interestingly those tests weren't failing with the earlier version of these changes against version 41.x.

@pcowgill
Copy link
Contributor Author

The test failure was because I did a find/replace relative to an earlier version master, so the changes were missing some new uses of res.body that needed to be changed to res in the latest version of master. The tests should be passing now 🤞

@pcowgill
Copy link
Contributor Author

It looks like the Travis failure is just it hitting a timeout, which I don't think is something that my PR would increase the probability of, perhaps something that's just stochastic?

@pcowgill
Copy link
Contributor Author

As for the codecov warnings, it looks like codecov never ran for #1183, so the difference may be from that PR

@alanshaw
Copy link
Contributor

alanshaw commented Jan 29, 2020

@pcowgill apologies I didn't get to this sooner. Did you look into adding a global afterResponse hook when in react native?

It might be less invasive to add a .body property to the response here with an async iterable that calls .arrayBuffer(). Then all the rest of the code can remain the same and it would be easier to remove when RN supports .body.

What do you think?

@pcowgill
Copy link
Contributor Author

@alanshaw To make sure I understand the suggestion, which file are you thinking that change would land in? Thanks!

@pcowgill
Copy link
Contributor Author

@alanshaw Curious for your thoughts on the codecov comment too!

@alanshaw
Copy link
Contributor

@alanshaw To make sure I understand the suggestion, which file are you thinking that change would land in? Thanks!

https://github.com/ipfs/js-ipfs-http-client/blob/e9aaa750beeb000f485fb31d43d2af648676dc8e/src/lib/configure.js#L40-L42

@elmariachi111
Copy link

Just checked out this PR because when I run jest on my setup (ionic / Typescript / React / node 12), and just test a simple ipfs.cat it fails with Cannot read property 'destroy' of undefined. This PR's fix works 99% around that issue by supporting res.arrayBuffer instead of res.body. But I think another cause / usage is hidden in error-handler#21 -> this line fails first on my machine. When I hack into it with

if ((isNode || isElectronMain) && response.body) response.body.destroy()

my jest tests are green again :)

@hugomrdias
Copy link
Contributor

we will be doing some changes around http requests handling soon to fix these issues, stay tuned.

@pcowgill
Copy link
Contributor Author

we will be doing some changes around http requests handling soon to fix these issues, stay tuned.

@hugomrdias That's great! Can you share any additional details about this? Thanks!

@pcowgill
Copy link
Contributor Author

pcowgill commented Mar 9, 2020

@pcowgill apologies I didn't get to this sooner. Did you look into adding a global afterResponse hook when in react native?

It might be less invasive to add a .body property to the response here with an async iterable that calls .arrayBuffer(). Then all the rest of the code can remain the same and it would be easier to remove when RN supports .body.

What do you think?

@alanshaw Sure, that suggestion works for me.

@hugomrdias Are you already planning on implementing the changes Alan described in the child package of the js-ipfs monorepo as part of the ky removal, or should I make a PR against the ky removal branch with these changes? (Assuming the ky removal branch will take at least a few more days to be merged.)

@pcowgill
Copy link
Contributor Author

pcowgill commented Mar 9, 2020

Will there still be the equivalent of an afterResponse hook after removing ky?

@hugomrdias
Copy link
Contributor

There will be no hooks and would advise against making the PR that specific problem needs to be fixed outside http-client

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants