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

No new timeouts after an error #652

Merged
merged 1 commit into from
Nov 6, 2018

Conversation

szmarczak
Copy link
Collaborator

Fixes #631

@sindresorhus
Copy link
Owner

@timdp Can you try this out?

@szmarczak
Copy link
Collaborator Author

request.once('error', () => {}); // Ignore the socket hung up error made by request.abort()

Hmm... Is it a good idea to ignore all socket hung up errors? If users do promise.cancel(), they won't see them, unless they do promise.on('request', request => setTimeout(() => request.abort(), n))

@timdp
Copy link

timdp commented Nov 5, 2018

@szmarczak I ran

yarn add 'szmarczak/got#fix-timeouts'

and the test from #631 worked as expected:

caught: { RequestError: getaddrinfo ENOTFOUND 1541424862699.dev 1541424862699.dev:80

However, it noticeably takes a while to execute. I added console.time() and consistently got execution times of just over two seconds. In the readme, it says that the time between retries is

1000 * Math.pow(2, retry) + Math.random() * 100

which, with retry = 0, means that the maximum execution time should be 1,100 ms plus a few milliseconds for the timeout, right? I don't get where the extra second goes.

@UltCombo
Copy link

UltCombo commented Nov 5, 2018

@timdp I can confirm there's a bug in the default retry delay logic.

The retries function gets 1 for the iteration argument in the first retry (see here), so the retry delay math is wrong (1 << 1 === 2).

@timdp
Copy link

timdp commented Nov 5, 2018

Indeed. The retry parameter starts at 1, not 0.

@timdp
Copy link

timdp commented Nov 5, 2018

Also, I want to point out that the concept of cancelers is basically what RxJS used to call Disposable until version 4. We still have some code that depends on it at our company. Just another argument to support what I originally said about async state, even if it's not very pragmatic. :-)

@szmarczak
Copy link
Collaborator Author

@UltCombo @timdp

if (iteration > retries) {
return 0;
}

with retry: 0 it should reject immediately. I'll check it tomorrow.

@timdp
Copy link

timdp commented Nov 5, 2018

Yeah, but my original reproduction of the issue used retry: 1, so I kept that and discovered a second issue.

@szmarczak
Copy link
Collaborator Author

Yup. It's a bug. From the docs:

Delays between retries counts with function 1000 * Math.pow(2, retry) + Math.random() * 100, where retry is attempt number (starts from 0).

Let's merge this PR then. I'll make another one for that to keep things organized :)

@sindresorhus sindresorhus merged commit d8dd881 into sindresorhus:master Nov 6, 2018
@szmarczak szmarczak deleted the fix-timeouts branch January 17, 2019 18:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants