-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should Cache#addAll reject with AbortSignal's reason if the signal is already aborted? #1684
Comments
Hey @CYBAI, thanks for raising this! It seems that none of @shaseley can you review this for Chromium? @asutherland can you review this for Gecko? |
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.) |
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. |
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
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.The text was updated successfully, but these errors were encountered: