Rate limit errors #354
Rate limit errors #354
Conversation
08f260e to
103145e
Compare
|
I think I have fixed the underlying problem in ad6be66; thanks to @clayreimann for the spot-on analysis. This has exposed a problem with the search tests, which are now failing. The Search API has its own rate limit, and I think the 403 errors are probably due to the four build jobs exhausting the limit. I'm going to mock out the search API too, with pre-recorded responses, to take care of this. (I also noticed the issue milestone tests fail intermittently. This appears to be a race condition between the four test runners creating and deleting the same milestone.) |
| @@ -49,6 +49,7 @@ | |||
| "debug": "^2.2.0", | |||
| "es6-promise": "^3.0.2", | |||
| "js-base64": "^2.1.9", | |||
| "nock": "^8.0.0", | |||
There was a problem hiding this comment.
This is used only in the test files, so it should be a devDependency not a dependency.
1ec082f to
6a30f26
Compare
| throw error; | ||
| } | ||
| }); | ||
| }).catch(callbackErrorOrThrow(cb, path)); |
There was a problem hiding this comment.
Looking at this again, I think you were on to something with this change in the first place, I think that perhaps it needed to be a bit more nuanced. Maybe something like:
.catch(function(error) {
// we haven't processed this error yet
if (!(error instanceof ResponseError)) {
callbackErrorOrThrow(cb, path)(error);
// we have already processed this error
} else if (cb) {
cb(error);
} else {
throw error
}
});Thoughts?
|
@divergentdave thanks for the PR, should the tests be passing? I also looked at your change to the |
|
Not yet, this still needs some work
|
|
Okay, 9ad8953 passes tests locally for me. (though some tests are flaky) I'm working on mocking out the search API requests, as described above, but I think the axios and nock libraries might be interfering with each other. |
5eb8cac to
6d54c6b
Compare
6d54c6b to
ae2fd3e
Compare
|
This is ready to go now. I figured out the search API fixtures, and I squashed some commits to clean up the history. Let me know if you have any questions! |
| if (object.hasOwnProperty('config')) { | ||
| const {status, statusText, config: {method, url}} = object; | ||
| let message = (`${status} error making request ${method} ` + | ||
| `${url}: "${statusText}"`); |
There was a problem hiding this comment.
Is there a reason to break this into two lines?
There was a problem hiding this comment.
|
@divergentdave Thanks for the great PR! |
|
You're welcome, happy to contribute!
|
|
Thank you very much indeed! |
Prior to 2.4.0, certain errors are not handled correctly, resulting in the reported error being an error in the error handler. This makes it impossible to know what the original error was. This was [fixed in 2.4.0](github-tools/github#354), meaning we will now get meaningful error reports for errors when interacting with the Gist API. Apparently the 2.4.0 build failed, so there is no 2.4.0 on npm. For that reason we include the dependency off of GitHub, which means `dist` isn't built, which means we need to compile in the source files. So, a bit of extra configuration in WebPack to compile ES6 and also to point at the right module lookup paths.
This fixes #348. So far I have added fixture data and failing tests.