13:06
<Dominic Farolino>
Async APIs return a rejected promise right away if a passed-in signal is aborted. Should sync APIs do the same? addEventListener() doesn't throw if the given signal is aborted, and I made Observable#subscribe() behave similarly. But I'm not sure if this should be a general rule or on a per-API basis.
13:08
<Dominic Farolino>
Context: WebMCP has a registerTool() method to register a JS function with a built-in agent. It throws if the tool can't be registered because the tool is invalid. We're now making it accept a signal, which when aborted, unregisters the tool. I'm leaning towards NOT throwing when registerTool() is given an already-aborted signal, but I can see how that's confusing since you might think registration was successful in the absence of an exception.
13:11
<Luke Warlow>
new CloseWatcher() also doesn't throw if given an aborted signal (it just automatically destroys the watcher). So I think given that the behaviour should be to do nothing. (Or to unregister if already registered).
13:15
<Luke Warlow>

I think my mental model is generally that

method({signal: AbortSignal.abort() })

should be roughly equivalent to:

const controller = new AbortController();
const signal = controller.signal;
method({signal});
controller.abort();
13:17
<Dominic Farolino>
OK that is my impression too, thanks for the feedback!