Intent to Ship: Fetch API: Forward reason from AbortController to fetch Response

[Chromestatus]

Contact emails

dead...@google.com

Specification

https://fetch.spec.whatwg.org

Summary

An AbortController can be passed into fetch to allow a request to be aborted; this is already supported see https://chromestatus.com/feature/5631483679080448 When calling abort, you can optionally pass in an "abort reason", and the original fetch promise if it hasn't resolved should be rejected with that reason. This is already working as intended. *However*, if the fetch promise *has* resolved (after reading the header), but the body has not yet been fully read, this is also intended to propagate the abort reason to the Response methods such as Response.blob(), as well as the ReadableStream Response.body. This part is not currently working; the relevant Promises instead are rejected with generic AbortErrors. Firefox at least is compliant here but chromium/Edge/Safari are not.

Blink component

Blink>Network>FetchAPI

Web Feature ID

abortable-fetch

Motivation

No information provided

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/fetch/api/abort/general.any.html Specifically the tests: * response.arrayBuffer() rejects with abort reason if already aborted (and other response methods such as body()) * Stream errors once aborted with abort reason. Underlying connection closed.

Flag name on about://flags

No information provided

Finch feature name

ForwardReasonToFetchBodyAbort

Rollout plan

(RARE) Experiment users ramp up over time

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/502133195

Estimated milestones

Shipping on desktop	153
Shipping on Android	153
Shipping on WebView	153
Shipping on iOS	153

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5158507786665984?gate=6176253840326656

This intent message was generated by Chrome Platform Status.

[Dan Clark]

> Specification

> https://fetch.spec.whatwg.org

Can you please give a more specific link into the part of the spec that defines this behavior?

> WebKit: No signal

Can you request a WebKit signal?

> Is this feature fully tested by web-platform-tests?

> Yes
> https://wpt.fyi/results/fetch/api/abort/general.any.html Specifically the tests: * response.arrayBuffer() rejects with abort reason if already aborted (and other response methods such as body()) * Stream errors once aborted with abort reason. Underlying connection closed.

I'm still unclear on which tests cover this change. Looking at the test results all are already passing in Chrome Stable except for "Readable stream synchronously cancels with AbortError if aborted before reading" which doesn't seem to match this scenario.

> Rollout plan

> (RARE) Experiment users ramp up over time

Can you say more about this roll out plan? This doesn't seem like the kind of thing that would need to be rolled out gradually via experiment.

Lastly please request the other "Prepare to Ship" reviews in the chromestatus entry (Privacy, WP Security, etc).

Thanks,

Dan

[Daniel Clark]

Thanks for pointing out the specific spec algos.

 

> @ricea had suggested using an experiment, I assume because the use of fetch is so widespread and changing the type of error that's thrown could have consequences, even if it's the intended behavior. But I'll let him comment on that himself if he has anything to add.  

 

We have generally been recommending against gradual rollout in cases like this: https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#prefer-waterfall-rollout-for-platform-changes. In short, an experimental rollout makes any breakage hard to track for developers because it won’t show up consistently. The usual approach would be to just ship normally via canary/dev/beta/stable and be ready to roll it back via finch if there are issues.

 

We shouldn’t do either without trying to understand the risk, though. What do you expect potential compatibility issues to look like for this? Do developers often have logic branching on specific abort values for these promises versus just logging them? Do we have Use Counters that could put a high bar on the risk, like a counter for how often already-completed fetches are aborted with a reason, or how often the Response methods are called for a fetch in this state?

 

From: Taylor Brandstetter <dead...@google.com>
Sent: Wednesday, August 12, 2026 2:30 PM
To: blink-dev <blin...@chromium.org>
Cc: Daniel Clark <dan...@microsoft.com>; Chromestatus <ad...@cr-status.appspotmail.com>; dead...@google.com <dead...@google.com>; Adam Rice <ri...@google.com>
Subject: Re: Intent to Ship: Fetch API: Forward reason from AbortController to fetch Response

 

You don't often get email from dead...@google.com. Learn why this is important

> Can you please give a more specific link into the part of the spec that defines this behavior?

Sure thing; the body methods point to the steps for consuming a body: https://fetch.spec.whatwg.org/#concept-body-consume-body

Which point to the steps for fully reading a body: https://fetch.spec.whatwg.org/#body-fully-read

Which say to read all the bytes from the reader.

And regarding the reader, the main abort steps (https://fetch.spec.whatwg.org/#http-network-fetch) say:

1. If fetchParams is aborted, then:
1. Set response’s aborted flag.
2. If stream is readable, then error stream with the result of deserialize a serialized abort reason given fetchParams’s controller’s serialized abort reason and an implementation-defined realm.

So, both the readable stream and all the body methods consuming it should be errored with the abort reason.

> Can you request a WebKit signal?

I didn't realize it was necessary just for filling a gap in the implementation, but the wide review documentation does call this case out, so I will request a signal and update the feature later.

> I'm still unclear on which tests cover this change.

I called them out there; "response.X() rejects with abort reason if already aborted" (for each body method) and "Stream errors once aborted with abort reason". They fail on everything but Firefox (well except for the latter which doesn't run on Firefox); I'm assuming the dashboard wasn't updated when you responded but you can see the failures now.

 

> Can you say more about this roll out plan? This doesn't seem like the kind of thing that would need to be rolled out gradually via experiment.

@ricea had suggested using an experiment, I assume because the use of fetch is so widespread and changing the type of error that's thrown could have consequences, even if it's the intended behavior. But I'll let him comment on that himself if he has anything to add.  

 

> Lastly please request the other "Prepare to Ship" reviews in the chromestatus entry (Privacy, WP Security, etc).

Will do. Thanks for your review, Dan.

[Taylor Brandstetter]

> Can you please give a more specific link into the part of the spec that defines this behavior?

Sure thing; the body methods point to the steps for consuming a body: https://fetch.spec.whatwg.org/#concept-body-consume-body

Which point to the steps for fully reading a body: https://fetch.spec.whatwg.org/#body-fully-read

Which say to read all the bytes from the reader.

And regarding the reader, the main abort steps (https://fetch.spec.whatwg.org/#http-network-fetch) say:

1. If fetchParams is aborted, then:

   1. Set response’s aborted flag.

   2. If stream is readable, then error stream with the result of deserialize a serialized abort reason given fetchParams’s controller’s serialized abort reason and an implementation-defined realm.
      

So, both the readable stream and all the body methods consuming it should be errored with the abort reason.

> Can you request a WebKit signal?

I didn't realize it was necessary just for filling a gap in the implementation, but the wide review documentation does call this case out, so I will request a signal and update the feature later.

> I'm still unclear on which tests cover this change.

I called them out there; "response.X() rejects with abort reason if already aborted" (for each body method) and "Stream errors once aborted with abort reason". They fail on everything but Firefox (well except for the latter which doesn't run on Firefox); I'm assuming the dashboard wasn't updated when you responded but you can see the failures now.

> Can you say more about this roll out plan? This doesn't seem like the kind of thing that would need to be rolled out gradually via experiment.

@ricea had suggested using an experiment, I assume because the use of fetch is so widespread and changing the type of error that's thrown could have consequences, even if it's the intended behavior. But I'll let him comment on that himself if he has anything to add.  

> Lastly please request the other "Prepare to Ship" reviews in the chromestatus entry (Privacy, WP Security, etc).

Will do. Thanks for your review, Dan.

On Monday, August 10, 2026 at 12:11:55 PM UTC-7 Dan Clark wrote:

[Alex Russell]

Hey Taylor,

I'm going to LGTM1 this on the basis that we do not have compatible behaviour between WebKit/Chromium and Gecko at the moment, reducing the likely risk of breakage. That said, we do need the other review bits filled in (via chromestatus), and my LGTM is contingent on those, as well as requests for positions to Mozilla and WebKit.

Best,

Alex

[Taylor Brandstetter]

> We shouldn’t [ship normally] without trying to understand the risk, though. What do you expect potential compatibility issues to look like for this? Do developers often have logic branching on specific abort values for these promises versus just logging them? Do we have Use Counters that could put a high bar on the risk, like a counter for how often already-completed fetches are aborted with a reason, or how often the Response methods are called for a fetch in this state?

I don't see any use counters specifically for providing an abort reason, no. Branching logic on the error from the promises would be the risk, although there's a good chance that we were just being overly cautious. I have no reason to believe this would be particularly common. If others are ok with it, I would suggest just shipping normally with 154. You mentioned being ready to roll back via finch; does that mean we would keep the change gated behind a flag, but roll it out to 100% immediately for 154 when it branches? I'm not very familiar with finch (or this process) so bear with me.

I requested the WebKit signal (https://github.com/WebKit/standards-positions/issues/711) and the other Prepare to Ship reviews, which I assume should be fairly trivial. I haven't requested Prepare to Ship for Adoption yet as it requires the feature to be stable for four weeks, and I just changed the milestone to 154.

[Dan Clark]

LGTM2, thanks for helping us consider the compat risks here. My recommendation to ship "normally" is to just set the feature flag to "stable" in main and let the change roll out through the normal release channels. Keep an eye out for bugs, and if there is some problem, that's when you'd use Finch to set the flag back off in the stable channel. As a non-Googler I can't speak to the process details of that, but hopefully a Googler can help if that does become needed.

[Taylor Brandstetter]

The Adoption gate should be filled out before shipping...where did you see a reference to "stable for four weeks"? 

One of the checkboxes is "Announcement lead time. This feature's name, summary, and milestones have been unchanged for the past four weeks".

Which I assumed didn't apply since I changed the milestone (153->154). However, if we ship it by enabling the feature flag on stable immediately—rather than going through canary/dev/beta first—it could actually ship in 153, as the code is ready. Shall I revert that change and proceed with the Adoption prepare to ship? The feature entry hasn't even existed for four weeks, though, is that a problem?

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/GrS94YdOTJI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cbe2d67-6dcf-4115-a456-22eebf737674n%40chromium.org.

[Daniel Clark]

To be clear on what I mean below is that you should enable the feature in Canary so that it goes through canary/dev/beta first before reaching stable. So if done now that’d ship to Stable in 154.

If that still doesn’t leave 4 weeks lead time you can leave that "Announcement lead time” box unchecked if it hasn’t been unchanged for that long and still request the Adoption review (after ensuring the other boxes are completed if they apply). The owners of that gate can comment if they think it needs more lead time; IMO it will likely be fine.

From: Taylor Brandstetter <dead...@google.com>
Date: Wednesday, August 19, 2026 at 12:37 PM
To: Daniel Clark <dan...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; Chromestatus <ad...@cr-status.appspotmail.com>; Adam Rice <ri...@google.com>
Subject: Re: [blink-dev] Re: Intent to Ship: Fetch API: Forward reason from AbortController to fetch Response

You don't often get email from dead...@google.com. Learn why this is important

The Adoption gate should be filled out before shipping...where did you see a reference to "stable for four weeks"? 

[Taylor Brandstetter]

Understood, thanks for the clarification.

[Daniel Bratell]

LGTM3

/Daniel

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK35n0bMvwnkbykO%2BvFEdc9Ke4Uaw2%2B6QmNchpVa8RNyEeoRoQ%40mail.gmail.com.