Re: [whatwg/fetch] Add a `timeout` option (#951)

@domenic Sorry! My goal was not to exaggerate things at all. My example was actually copied and modified from https://github.com/whatwg/fetch/issues/20#issuecomment-323740783 and I didn't try to optimize it. You're totally right that it can be simplified a little bit though. 

I feel like the gravity of the situation didn't come across though…

**This is something that needs to happen for pretty much every `fetch` call in an application, or you leave yourself open to infinite hanging bugs.**

For that level of severity, I do not think it's possible that the current `AbortController` API is going to get us there on its own. Again, I have nothing against it. It's extremely flexible, and seems designed well for extensibility and for low-level use. But there's no way it's going to be clear enough to be used for **every** request in an application. The first example you gave is confusing because `abort` appears to be called no matter what, since it's never cleared.

And I'm not talking about utility libraries **on purpose**.

Again… I'm talking about the average use of `fetch` resulting in a program hanging indefinitely. Having to import a library just to solve that means that `fetch` on its own isn't really useable as a solution for people. That's severe! It means that people directly using `isomorphic-fetch` in their app are likely not writing stable code.

---

@Pauan I think you've missed the core of what I'm saying. (Not to mention the example you gave seems kind of incomplete, and doesn't seem grounded in any real-world use cases.)

I'm talking about how the `fetch` library can eliminate its current limitation where it has infinite hanging uncertainty. If you look at your example again, you'll notice that the solution I proposed has actually eliminated the uncertainty. The code you written, given the `timeout` option, is guaranteed to execute to completion, and not hang indefinitely. When the headers only are read, it will timeout for the headers. And in the `if` statement when the body is read, it will timeout for both the headers and body. Guaranteeing that its caller will receive control again no matter what happens to the HTTP response.

That's the whole point.

It seems like you're not thinking in terms of the user's expectation. The `timeout` property in the solution I proposed does actually have clear behavior from the user's point of view. **It will always ensure that, whatever the amount of data I read from the response is, it always completes in a given duration. And it never results in infinitely hanging.**

---

Again… the core of what I'm talking about is that the current `fetch` API makes it **extremely** easy to write code that will hang indefinitely. And people are currently unaware of these bugs.

This problem is widespread. [This blog post](https://davidwalsh.name/fetch-timeout) comes up as one of the first results for "fetch javascript timeout" in Google, but it actually still can hang indefinitely when you `await res.json()`.

[This accepted stackoverflow answer](https://stackoverflow.com/questions/46946380/fetch-api-request-timeout) has the same issue, it can infinitely hang. **This is widespread.**

Having a simple `timeout` option seems critical to me to avoid these kinds of bugs. Otherwise we're going to have to start telling people to avoid using `fetch` directly, which is really unfortunate. To write good HTTP-related code you **have** to use timeouts, there's no two ways about it. And the `AbortController` API we have currently doesn't make that easy.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/951#issuecomment-541380365