Re: [whatwg/dom] Request for a different type of example of abort steps (Issue #1031)

I guess this is a question of whether we want Promise-rejection-as-a-result-of-abortion to be a good signal for whether the underlying operation truly got canceled, or to a lesser extent had side-effects, right?

E.g., if I do `const p = fetch("/foo", {method: "POST", signal, ...})`, and then abort the fetch sometime later, should:
 1. `p` only reject if were able to meaningfully cancel the underlying operation (fetch), and in this case I can be assured that the POST didn't touch anything, or..
 2. `p` reject immediately, and cancel the fetch best-effort

Fetch does (2), but at least one other user of AbortController/Signal I'm aware of does (1), and I'm commenting here as a result of reviewing code in Chromium that is leaning towards doing (1) too.

A related question is: should it be possible for promise-returning APIs to ever resolve after we `abort()` the underlying operation? If we prefer (1) above, then certainly. If (2), then I'm not sure it's possible to ever see the promise resolve after calling abort(). I'd expect abort() to immediately reject the promise (something we could add in the normative requirements in https://dom.spec.whatwg.org/#abortcontroller-api-integration if we wanted), so that in the next microtask the promise is indeed rejected. The only way to see a promise resolve after `abort()` is if in the same task that `abort()` is called, `Reject()` is called just before it.

Between (1) or (2), I am not sure which is a better model or which way most usages of AbortController/Signal lean. I am not even sure if we want to prescribe a one-size-fits-all guideline in https://dom.spec.whatwg.org/#abortcontroller-api-integration, or just leave it up to each consumer API.

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

Message ID: <whatwg/dom/issues/1031/1233206400@github.com>