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

> So this PR seems to be halfway between the simple version and the complex version.
> 
> The simple version here ignores service workers. For that, I think you don't need any serialization/deserialization; in fact, I don't think you need the "cloned error" concept at all. You just need the changes you made to fetch(), where if the signal is already aborted, or if the abort steps for the signal are triggered, you reject the returned promise with the signal's reason, instead of with an "AbortError" DOMException.
> 
> The complex version involves updating the `request.signal.reason` seen in a service worker, when the main page does `controller.abort(reason)` from outside the service worker. This requires more plumbing than what you have here; in particular, you need to specify how the message gets sent across realms.

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 don't understand @noamr's recommendations about how to use the controller for this. In particular I don't understand how we go from "abort a fetch controller with a `reason` JavaScript object" to "post a message to the service worker realm containing the `Request` representing this request, to signal abort on that `Request`'s [signal](https://fetch.spec.whatwg.org/#request-signal) using a deserialization of that request". Maybe he can suggest how this would best be done...

I think I might have been or still am confused about how this is observable. @nidhijaju, as I said WPTs would go a long way here to explain. Maybe I was proposing a solution for only part of the problem - which is aborting the navigation preload and I was missing a totally separate aspect.



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

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

Received on Tuesday, 9 August 2022 08:44:59 UTC