Don't use AbortSignal::Follow in fetch and cache-storage #39951
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
AbortSignal's "follow" algorithm is replaced with a new algorithm for
creating a dependent abort signal ([1], [2]), which is implemented as
a new AbortSignal constructor. This CL replaces Follow with the new
ctor, behind the AbortSignalAny REF.
There is a slight compat risk with the change (when the feature ships):
fetch: abort is propagated to dependent signals after abort event
dispatch for a signal, whereas "follow" propagated abort before (as
abort algorithms), which is observable. We could alternatively use
weak abort algorithms in AbortSignal.any(), but that would be more
complicated and partially limit GC optimizations.
cache: The use of "follow" in cache.addAll was not specced and
could lead to abort events firing when they shouldn't have. The new
behavior preserves the specced behavior (aborting outstanding
requests on failure) without dispatching events when abort is
triggered internally.
Note: the virtual test expectations match the current expectations
except for the test modified in fetch/api/abort/general.any.js.
[1] whatwg/dom#1152
[2] whatwg/fetch#1646
Bug: 1323391
Low-Coverage-Reason: the uncovered lines in request.cc are covered by WPT tests
Change-Id: I5c25048fcf9f8db759e2f0181ac338c8b603b451
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4515276
Reviewed-by: Nidhi Jaju <nidhijaju@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1144953}