Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add abort reason to abort fetch #1343

Merged
merged 31 commits into from
Oct 5, 2022
Merged

Add abort reason to abort fetch #1343

Changes from 5 commits
Commits
Show all changes
31 commits
Select commit Hold shift + click to select a range
a18ee76
add abort reason to abort fetch
nidhijaju Oct 27, 2021
6e0fe40
add name to acknowledgments
nidhijaju Oct 27, 2021
4a06427
remove if condition
nidhijaju Oct 27, 2021
eb499b4
use aborted predicate
nidhijaju Nov 1, 2021
c0833a5
fix
nidhijaju Nov 1, 2021
55d734e
Merge branch 'whatwg:main' into update-with-abortreason
nidhijaju Jul 25, 2022
4df5ef6
use aborted predicate
nidhijaju Nov 1, 2021
75d4bad
make changes
nidhijaju Aug 4, 2022
b6ddcaa
fix syntax
nidhijaju Aug 4, 2022
ba73b86
address comments
nidhijaju Aug 4, 2022
ddd1628
Apply suggestions from code review
nidhijaju Aug 9, 2022
62edcfe
Merge branch 'whatwg:main' into update-with-abortreason
nidhijaju Aug 15, 2022
14dac0d
incorporate review comments
nidhijaju Aug 15, 2022
8194bf6
update abort controller
nidhijaju Aug 15, 2022
f660a6e
update fetch()
nidhijaju Aug 15, 2022
2255611
move serialization to abort fetch
nidhijaju Aug 15, 2022
f44930c
pass reason to cancelAlgorithm
nidhijaju Aug 15, 2022
122bae5
address comments
nidhijaju Sep 6, 2022
cc54cd6
rename abort fetch
nidhijaju Sep 7, 2022
647f4f5
Apply suggestions from code review
nidhijaju Sep 7, 2022
e5b0236
Merge branch 'whatwg:main' into update-with-abortreason
nidhijaju Sep 28, 2022
1b86ddc
resolve conflict
nidhijaju Sep 28, 2022
b6a779d
fix
nidhijaju Sep 28, 2022
6a0f4aa
wrap fetch with <code>
nidhijaju Sep 28, 2022
63ad081
deserialize abort reason
nidhijaju Sep 30, 2022
f86437e
use controller's reason
nidhijaju Sep 30, 2022
38ea956
fix indentation
nidhijaju Sep 30, 2022
662fe10
fix deserialization & make serialized reason default undefined
nidhijaju Oct 3, 2022
70ade67
fix indentation
nidhijaju Oct 3, 2022
a29fd77
wrap abort fetch calls in <code>
nidhijaju Oct 3, 2022
01a87c0
Go back to null instead of undefined, address logic sharing comment, …
annevk Oct 4, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 15 additions & 9 deletions fetch.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7428,12 +7428,15 @@ method steps are:

<li><p>Let <var>request</var> be <var>requestObject</var>'s <a for=Request>request</a>.

<li><p>Let <var>error</var> be <var>requestObject</var>'s <a for=Request>signal</a>'s
<a for=AbortSignal>abort reason</a>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the modifications to fetch() work as written. Remember, they are running synchronously, while the fetch proceeds in parallel. So consider code like this:

const controller = new AbortController();
const p = fetch(url, { signal: controller.signal });
setTimeout(() => controller.abort(new Error("boo!")), 1000);

In your inserted step 4 here, you set error to a clone of controller.signal.reason. But controller.signal.reason is undefined, because controller.abort() is not called yet. So when we get down to step 14+15, we will serialize undefined and store it, which is pretty useless.

What happens if we just remove steps 14+15?


<li>
<p>If <var>requestObject</var>'s <a for=Request>signal</a>'s <a for=AbortSignal>aborted flag</a>
is set, then:
<p>If <var>requestObject</var>'s <a for=Request>signal</a> is <a for=AbortSignal>aborted</a>,
then:

<ol>
<li><p><a>Abort fetch</a> with <var>p</var>, <var>request</var>, and null.
<li><p><a>Abort fetch</a> with <var>p</var>, <var>request</var>, null, and <var>error</var>.

<li><p>Return <var>p</var>.
</ol>
Expand Down Expand Up @@ -7461,7 +7464,8 @@ method steps are:
<ol>
<li><p>Set <var>locallyAborted</var> to true.

<li><p><a>Abort fetch</a> with <var>p</var>, <var>request</var>, and <var>responseObject</var>.
<li><p><a>Abort fetch</a> with <var>p</var>, <var>request</var>, <var>responseObject</var>, and
<var>error</var>.

<li><p><a lt=terminated for=fetch>Terminate</a> the ongoing fetch with the aborted flag set.
</ol>
Expand All @@ -7479,8 +7483,8 @@ method steps are:
<li><p>If <var>locallyAborted</var> is true, terminate these substeps.

<li><p>If <var>response</var>'s <a for=response>aborted flag</a> is set, then <a>abort fetch</a>
with <var>p</var>, <var>request</var>, and <var>responseObject</var>, and terminate these
substeps.
with <var>p</var>, <var>request</var>, <var>responseObject</var>, and <var>error</var>, and
nidhijaju marked this conversation as resolved.
Show resolved Hide resolved
terminate these substeps.

<li><p>If <var>response</var> is a <a>network error</a>, then <a for=/>reject</a> <var>p</var>
with a {{TypeError}} and terminate these substeps.
Expand All @@ -7494,11 +7498,12 @@ method steps are:
<li><p>Return <var>p</var>.
</ol>

<p>To <dfn>abort fetch</dfn> with a <var>promise</var>, <var>request</var>, and
<var>responseObject</var>, run these steps:
<p>To <dfn>abort fetch</dfn> with a <var>promise</var>, <var>request</var>,
nidhijaju marked this conversation as resolved.
Show resolved Hide resolved
<var>responseObject</var>, and an optional <var>error</var>, run these steps:

<ol>
<li><p>Let <var>error</var> be an "<code><a exception>AbortError</a></code>" {{DOMException}}.
<li><p>If <var>error</var> is not given, let <var>error</var> be an
"<code><a exception>AbortError</a></code>" {{DOMException}}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error is always given I think, but it can be undefined. I think the text here and in Streams suggest we should have this primitive in DOM.

Something like

To get an error for an abort reason, given a JavaScript value reason, run these steps:

  1. If reason is undefined, then return a new "AbortError" DOMException.
  2. Return reason.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative might be to pass the signal on and then we define

The error of an AbortSignal object signal is ...

That might make it a bit easier to use. I.e., callers can say "throw signal's error".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But can it ever be undefined? It seems both AbortController#abort and static AbortSignal.abort sets the reason if undefined.


<li>
<p><a for=/>Reject</a> <var>promise</var> with <var>error</var>.
Expand Down Expand Up @@ -8079,6 +8084,7 @@ Moritz Kneilmann,
Ms2ger,
Nico Schlömer,
Nicolás Peña Moreno,
Nidhi Jaju,
Nikhil Marathe,
Nikki Bee,
Nikunj Mehta,
Expand Down