Skip to content
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

Fix multipart bodies vanishing #98

Closed
wants to merge 3 commits into from

Conversation

afirstenberg
Copy link

If a command is created withMedia() and that command fails because the authentication has expired, the retry (after the auth has been fetched) does not seem to have the bodies associated with the multiparts. This patch is a bit of a kludge, since it simply makes a copy of the multipart bodies and sets them back as part of the request after the auth succeeds.

When re-authing during a multipart, the bodies of the multipart appear to be empty. This keeps a copy of the body and reconstitutes the body on the second call.
@rakyll
Copy link
Contributor

rakyll commented Nov 5, 2013

@afirstenberg, could you lint with closure linter and please add a test?

bodies.forEach( function(body,i){
opts.multipart[i].body = body;
});

that.request(opts, opt_callback, true);

This comment was marked as spam.

This comment was marked as spam.

@jbergknoff
Copy link
Contributor

I investigated this a few weeks ago and the bug is actually in the "request" library. My workaround was to refresh my access token before each request, rather than relying on the auto-refresh.

@afirstenberg
Copy link
Author

@rakyll - I've linted, but coming up with a test is more difficult. I went to base it on the existing test for replaying a request after reauthing, but that test is marked as TODO. And I assume I came up with the same difficulty - having to wait for the timeout period as an actual part of the test

@rakyll
Copy link
Contributor

rakyll commented Dec 3, 2013

I don't remember exactly why the test for refreshing is left as a TODO, I will try to implement it today. On the other hand, why don't we upstream the fix to requests lib instead of hacking around it?

@rakyll
Copy link
Contributor

rakyll commented Dec 3, 2013

Taking a look at request, due to the stateful nature of Request, keeping the multipart as it is may be problematic and may cause bugs in the future. So, my proposal is to keep an exact copy of the original opts once it's passed to https://github.com/google/google-api-nodejs-client/blob/master/lib/auth/oauth2client.js#L192. What do you think?

@afirstenberg
Copy link
Author

Makes sense. It certainly reduces the risk of what Request might do with the options in a later version.

My biggest concern when I proposed the change I did was how deep a copy was going to be necessary and concerns about doing too-deep a copy and making an unnecessary copy of what might be a very large buffer. Since I didn't have a lot of experience with node, I was being conservative on what to preserve from call to call.

@rakyll
Copy link
Contributor

rakyll commented Dec 3, 2013

The memory efficient solution would be replaying request's Request object rather than creating a new one. I dont know if there are public interfaces to change headers, etc. If there are, I should fix transporter to expose the Request instance and replay it. Sounds very hacky though.

@jbergknoff
Copy link
Contributor

Any thoughts on switching from the request library, which is bloated and buggy, to something like needle (https://www.npmjs.org/package/needle)?

@ryanseys
Copy link
Contributor

Should be fixed in 1.0.3. Will no longer try to re-request if auth fails, but will try to refresh the access token before the request if it believes the access token has expired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants