I'm a bit conflicted about this.
How would justify expending the API surface when this can already be addressed via the rxjs timeout operator ?

That's a fair point, but this was mostly in reaction to this PR getting nowhere and seemingly being wanted by people:
#36681 (and also our own needs for this)

With this issue: #34421

While I agree with adding a timeout to eliminate the need for an RxJs timeout, especially since fetch handles this natively, I would expect an aborted fetch request to result in a standard TimeoutError, DOMException. This would also simplify handling TimeoutError errors differently, such as implementing a retry mechanism.

Just to avoid any confusion, since RXJs also has a TimeoutError interface. You mean throwing new DOMException('', 'TimeoutError')?
https://developer.mozilla.org/en-US/docs/Web/API/DOMException#timeouterror

Yes, when not using fetch. With fetch this is be handled out of the box.

I don't know how Angular works internally when it comes to polyfills, but after looking into it, I'd need to use AbortSignal.any() in order to support the Observable unsubscription and the timeout at the same time. But looking at caniuse, that function only has a 83% support rate. Is that acceptable?

https://caniuse.com/mdn-api_abortsignal_any_static

Angular doesn't provide any polyfills also we need to support at least the last 2 major versions of the browsers. Safari implemented it in the current major which makes it a no-go.

So until then, we'd need to use the setTimeout method for fetch instead of combining the two signals.
And when the signal is aborted from the setTimeout callback, it would be constructed as such new DOMException("signal timed out", "TimeoutError").

According to MDN TimeoutError is a legacy error code: https://developer.mozilla.org/en-US/docs/Web/API/DOMException#timeouterror
And hypothetically, even if a DOMError is given "unsupported" error names, they are still being constructed.

That looks like the correct alternative.

Beside the pending review, you'll need to update the "golden files". You can do this by running yarn bazel run //packages/common:common_api.accept.

I updated the code with the suggestions, however that command fails for me. I'm currently on Windows and am getting this error (Bazel always gives me some trouble):
java.io.IOException: ERROR: src/main/native/windows/processes-jni.cc(408): NativeProcess:WriteStdin(17472): Le canal de communication est sur le point d?Ωtre fermΘ.

I'll be away for a bit more than two weeks and won't be able to address this until then, when I can be on my normal machine.

Got back from holidays and got the command to work on my non-Windows machine (I'm not sure if that's supposed to only work on Unix-like systems).
Is there anything else you need me to do besides squashing the commits when we're done?

I had to remove the test for what's in the DOMException. I have no idea why, but during unit tests, the information Exception doesn't get treated like in actual browsers and NodeJS.

expect((err.error as DOMException).name).toBe('TimeoutError'); Would incorrectly say it's undefined instead of 'TimeoutError'. I'm fairly confident this isn't an issue with my code, since the test that checks for instanceof DOMException does actually pass.

Our tests run both in NodeJS and in actual browsers. You could guard your test like we already do in some other tests.
Here is an example:

Btw, the CLA job is red because you authored commits with 2 different addresses : <vi****t​@lycoops.be>
& <vinc********ops​@horus-software.be>

Yes, I know that, I'm still not on the same two computers. I'll squash the commits when everything is okay with my private account.

However I'm not sure why DOMException gets mocked in NodeJS. Is there a difference between DOMException in Node and in browsers? It seems to me that naive tests give always the same results when using it.

This seems like a known issue:

• Thrown AbortErrors are not DOMExceptions nodejs/node#40692

I stumbled upon that issue as well, but from my understanding it seems to not be related.

When I run in Node.Js

const e = new DOMException('', 'AbortError');

console.log(e.name);

I still get "AbortError". But undefined in tests. So it somehow gets eaten at some point.

That said, I don't know how important it is to you guys at the end of the day.

Sorry I had missed @ajitzero's comment