Should Cache#addAll reject with AbortSignal's reason if the signal is already aborted?

[CYBAI]

Based on https://dom.spec.whatwg.org/#dom-abortsignal-abort, when a signal is aborted, the abort reason would be set to the given reason or a new AbortError DOMException.

Currently, in Step 5-7-3-1 in https://w3c.github.io/ServiceWorker/#dom-cache-addall, it says

If response’s aborted flag is set, reject responsePromise with an "AbortError" DOMException and abort these steps.

so it will always reject the response promise with an AbortError DOMException.

Should it reject with the signal's abort reason instead?

Note: In fetch method, in Step 4-1, when the signal is already aborted, fetch will reject with the signal's reason.

[annevk]

Hey @CYBAI, thanks for raising this!

It seems that none of addAll() accounts for the fact that each request can be aborted. I agree that it would make sense to adhere to the same logic as fetch() uses and propagate the first exception thrown.

@shaseley can you review this for Chromium?

@asutherland can you review this for Gecko?

[asutherland]

It seems that none of addAll() accounts for the fact that each request can be aborted. I agree that it would make sense to adhere to the same logic as fetch() uses and propagate the first exception thrown.

Agreed. This is also consistent with the naming of Promise.all() which also rejects on the first rejection with the first rejection reason. (Versus Promise.allSettled which will provide all rejections.)

[shaseley]

Oh, looks like we're not using the input Request object signals at all? Good catch; +1 propagating the first exception/abort reason, whether from an associated signal or other reason.