Re: [whatwg/fetch] Add abort reason to abort fetch (PR #1343)

> > Why is that necessary? The aborted error is a result of serialization, so by definition it's transferrable between realms, and the main question is when is it serialized. We don't specify how fetch messages the service worker realm to abort in more detail than that today.
> 
> I'm unsure what you're asking about. Are you questioning the goal of updating `request.signal.reason` for the service worker realm's `Request` object? That seems to be what people were indicating a desire for in, e.g., [#1343 (comment)](https://github.com/whatwg/fetch/pull/1343#issuecomment-960474944) and preceding messages.
> 
> Or are you asking why you need plumbing to do this? Well, there's nothing in the current PR which updates that value, so that's why I suggested adding spec text to do so...

You answered my question, I indeed guided @nidhijaju to solve the wrong problem, though the fetch part of the solution holds.

I believe what we need to do something like the following:
- In fetch, serialize the reason immediately when abort(reason) is called, and save realm-agnostic result in the controller as this PR does
- In [handle fetch](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm), create an AbortController, and when we create the `Request` object, associate it with that controller's signal
- If the fetch is aborted, also abort the created controller with the fetch controller's serialized abort reason ("cloned error" in this patch).
WDYT?


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1343#issuecomment-1209181233
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1343/c1209181233@github.com>