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

Request not cancelled when timeout occurs #221

Closed
fruitraccoon opened this issue Jan 16, 2020 · 4 comments · Fixed by #238
Closed

Request not cancelled when timeout occurs #221

fruitraccoon opened this issue Jan 16, 2020 · 4 comments · Fixed by #238
Labels
bug Something isn't working

Comments

@fruitraccoon
Copy link

fruitraccoon commented Jan 16, 2020

When a Ky request times out AND no explicit signal was passed in the options, the request is not being cancelled.

Reproduction stackblitz here - when the code runs it makes two requests to GET root. In Chrome's dev tools, the first request is shown to be cancelled, but the second is not.

Looking at the code, it appears the issue is with this line. The this._options.signal is only set if there's already a signal set on the options.

This initial PR that added the cancel functionality had this coded differently but it was changed in PR 180. It does not appear that the change in behaviour was intended?

I've worked around this issue for now by setting a (never used) signal in the default options for ky, but I thought it worth reporting.

Edit: Tested Ky version: 0.16.1

@sholladay sholladay added the bug Something isn't working label Jan 16, 2020
@sholladay
Copy link
Collaborator

Yes, you are correct. I messed this up during refactoring in PR #180.

Thank you for reporting this!

@fruitraccoon
Copy link
Author

Not a problem!

Just an update about my work-around (in case anyone else tries it) - unfortunately if you have a signal set on the default options, and then try to set another signal for a specific call, you get an exception (cryptically, TypeError: this._options.signal.addEventListener is not a function).

This is because when you have two signals, when Ky calls its deepMerge to combine them it unsuccessfully attempts to merge the signals together and the result is that options.signal is set to an empty object.

Personally I don't think this is a big deal, because in real usage it doesn't make a lot of sense to set a signal in the default options anyway 🙂

@sholladay
Copy link
Collaborator

sholladay commented Jan 16, 2020

Agreed that it doesn't make much sense to use the signal option with ky.create() or ky.extend(). That's an interesting quirk, nonetheless. One that's probably worth fixing unless doing so is complicated. My expectation would be for Ky to only try to merge plain objects, thus signal should get overridden rather than merged, given that it is a non-plain object.

We could copy the algorithm from is-plain-obj.

@fruitraccoon
Copy link
Author

That approach makes sense to me, and it would make the default options behaviour more robust. Nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants