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
Comments
Yes, you are correct. I messed this up during refactoring in PR #180. Thank you for reporting this! |
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, This is because when you have two signals, when Ky calls its 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 🙂 |
Agreed that it doesn't make much sense to use the We could copy the algorithm from is-plain-obj. |
That approach makes sense to me, and it would make the default options behaviour more robust. Nice. |
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
The text was updated successfully, but these errors were encountered: