cryptic error message for already aborted signals

[jimmywarting]

Undici have the most crypting error message when sending in an already aborted signal.

example:

fetch('http://localhost', { signal: AbortSignal.abort('Already aborted') })
  .catch(e => console.log({ctor: e.constructor.name, code: e.code, message: e.message}))

undici:

{ ctor: 'TypeError', code: undefined, message: 'invalid_argument' }

Chrome:

{ ctor: 'DOMException', code: 20, message: "Failed to execute 'fetch' on 'Window': The user aborted a request."}

Safari:

{ ctor: "DOMException", code: 20, message: "Request signal is aborted"}

Firefox & Deno:

{ ctor: "String", code: undefined, message: undefined }
// returns the abort reason, so the result is "Already aborted"

// With an undefined reason it throw
{ ctor: "DOMException", code: 20, message: "The operation was aborted. " }

i tough i sent in something really wrong type when i was calling fetch when i received a TypeError.
but it's of a correct "type".

{ signal: "foo" } is an TypeError and a invalid argument.

[ronag]

@KhafraDev

[KhafraDev]

the error comes from

undici/index.js

Line 109 in 68e2275

Error.captureStackTrace(err, this)

but I think undici would be in the right here by throwing the signal's reason "Already aborted" because of the first 4 steps of https://fetch.spec.whatwg.org/#dom-global-fetch. I think firefox's behavior is right here, idk.

[jimmywarting]

I guess firefox and Deno's behavior is also right.
It have more value by rejecting with the signals own reason... so that you know why it got aborted.

reason why you get a DOMException when undefined is passed is b/c:
AbortSignal.abort().reason.constructor === DOMException

[KhafraDev]

it was the correct behavior before a spec change that made requests abort with the signal's reason rather than the standard error from abortsignals