Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

> Yeah, I thought this was resolved with the decision that abort() would be async, resolving with a boolean of whether the request was actually aborted or if it had already ended by the time the abort was evaluated.

I think it would be helpful for implementations to agree on some points where abort has consistent behavior.  The current FF prototype has this weirdness currently:

https://bugzilla.mozilla.org/show_bug.cgi?id=1349950

So this code:

```
const url = '/';
const controller = new FetchController();
const signal = controller.signal;
const observe = (observer) => {
  observer.addEventListener('statechange', event => {
    console.log('state changed to ' + observer.state);
    if (observer.state === 'responding') {
      console.log('Calling abort!');
      controller.abort();
    }
  });
}

fetch(url, {signal, observe}).then(r => {
  console.log('fetch() resolved with a Response');
  return r.text();
}).then(text => console.log(text)).catch(err => {
  if (err.name == 'AbortError') {
    console.log('The request/response was aborted');
  } else {
    console.log('Unexpected error: ' + err.name);
  }
});
```

Outputs this on jsbin for me:

```
    "state changed to responding"
    "Calling abort!"
    "state changed to aborted"
    "state changed to complete"
    "fetch() resolved with a Response"
    ""
```

Note that the state changes to "aborted", but the final Response and .text() output resolve.  This seems wrong?  I would expect that if `.abort()` is ever called before state changes to "completed" then the promises should reject with AbortError.

-- 
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/447#issuecomment-292230249