Closed jasnell closed 3 months ago
For Cloudflare Workers, the key usecase that I can imagine supporting is the Timeout case, described in the explainer:
const signalWithTimeout = AbortSignal.any([signal, AbortSignal.timeout(10_000)]);
const response = await fetch(tile.url, {signal: signalWithTimeout});
With this example, signalWithTimeout
will trigger either when signal
is triggered or after 10 seconds, whichever happens first.
I like the layering of this in that it does not modify signal
in any outwardly observable way.
One thing that I've asked about before (and would still like to have) is the ability to cancel an AbortSignal
-- that is, effectively mark it as no longer be relevant. e.g.
const signal = AbortSignal.timeout(10_000);
// The signal will trigger after 10 seconds.
signal.cancel(); // or signal.close()
// The signal is canceled and will never trigger. All abort event handlers can be released.
This is a separate discussion, however. The two would pair nicely with one another tho.
Cloudflare currently has no plans for implementing TaskSignal
so I am largely ignoring all of the use cases in the explainer involving that.
Another relevant thread here: https://github.com/whatwg/dom/issues/1082
There's no further action to be done here. AbortSignal.any(...)
was added to the spec.
Cancelling an AbortSignal sounds interesting. We should then also add a way to re-engage it later. We could use this to enforce timeouts for tasks on low-priority queues only when there are tasks in a higher-priority queue.
One of the active discussions at the whatwg/dom repo is creation of an AbortSignal that can follow other AbortSignals... see https://github.com/whatwg/dom/issues/920
There is a proposal on the table for
AbortSignal.any()
here: https://github.com/shaseley/abort-signal-any/blob/main/README.mdThe key question for this group is whether the proposal looks good and whether wintercg has any feedback for the discussion.