Re: [whatwg/fetch] Attach timing info and URL to network errors, and report for fetch API (#1311)

That's not what I meant. Basically when there's a request we get a response from the server. Then we start processing the response while also processing its body *in parallel*. Processing its body in parallel eventually calls "process response done" (through finalize response), but if processing the response turns into a network error that will also want to call "process response done" (through finalize response). The question is whether the latter always happens before the former.

And I don't think that's necessarily the case when integrity is involved as that also awaits the body.

Two questions then:

1. Is that the only problematic case?
2. How do we solve this? The fundamental problem here is the finalize response call from the place where we are receiving bytes from the network as we are not certain at that point whether that is the final response. Here is a rough idea:
   * Fetch finale adds a listener to response if the response is not a network error. (If it is a network error it can invoke finalize response itself.)
   * Where we are receiving bytes from the network we check if a listener was added and only then do we invoke it. (I suppose this could also be a flag of sorts.)
   * To avoid race conditions, where we are receiving bytes from the network also sets the done flag.
   * Fetch finale also checks the done flag and if the done flag is already set it doesn't add a listener and invokes finalize response directly. It also sets the done flag for network errors.
   * Finalize response no longer deals in the done flag.

I'd love review from @yutakahirano and maybe @ricea on this, as well as you @noamr and @yoavweiss.

-- 
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/pull/1311#issuecomment-938587039