Node AbortError Behavior meeting

[benjamingr]

Hey, the issue of "what errors do we abort with?" was raised up multiple times in PRs by several users.

Other than "because of the primitive, aborting should always cause an error" I'm not sure we have consensus on anything.

I figured it would be useful to get interested parties in one room a-la-summit-style and talk this through.

Please feel free to suggest items for the agenda below.

Pinging people I talked to about this from Node in issues:

• @mcollina
• @jasnell
• @ronag

Pinging people I talked to about this as well but are not node core:

• @bterlson (TC39, azure SDK maintainer, looking into improving AbortSingal)
• @littledan (TC39, is Daniel a project member I always see him in events 😅 also very helpful and helping with this)
• @MadaraUchiha (wrote the HTTP2 AbortSignal PR)
• @benlesh (RxJS author whom I talked to a lot about AbortSignals and seemed interested).

I'm also going to ping @jakearchibald in case he can make it because I think his feedback would be very valuable, though I know he's busy - worth a shot :]

---

I want to make it clear that participation is not limited to the above people or to people from the Node org or any standards body. If you are interested in cancellation and feel like you can contribute to this decision please speak up and let me know.

Doodle

https://doodle.com/poll/ug26rc9cnmeuacr4

Agenda

• Overview of AbortSignal in the WHATWG DOM spec and their guidance regarding aborting actions.
• Discuss how user code typically aborts code and how controllers/signals are used.
• Discuss how user code typically checks for aborted operations:
  • Do we want different aborts to have different .codes or the same code?
  • Do we want our AbortErrors for core APIs to be DOMExceptions or not? (e.g. backporting/userland code implications for readable-stream).
  • How should users identify Abort errors? (Do we want to supply specific codes for Node specific APIs and provide .name === 'AbortError' for web compatibility?

Out of scope:

• Usability improvements for AbortSignal (very interesting, but not for this meting).

[benjamingr]

Update, due to family reasons of a certain person we want to attend we'll try to make this next week and not the week after. I will update the doodle soon

[benjamingr]

Update: new doodle, sorry https://doodle.com/poll/ug26rc9cnmeuacr4 ping @MadaraUchiha @ronag and @mcollina

[mcollina]

Done

[benjamingr]

Looks like we converged on a time :] I've sent you all a calendar invite with a zoom link - if anyone else wants to attend you are welcome to (send me an email and I'll add you to the invite). The time is also updated on the doodle.

[ronag]

@benjamingr I don't think I received an invite.

[benjamingr]

I sent it to your iCloud account @ronag - I will re-invite you

[ronag]

It ended up in spam. Fixed. Thanks!

[jakearchibald]

I don't think I got an invite btw

[benjamingr]

@jakearchibald sorry, I only sent it to people who filled the doodle - I sent you an invite now :]

[benjamingr]

Made an empty doc to (hopefully) summarise during the meeting https://docs.google.com/document/d/1aZzdQbo2G2wpGewxnkXaBoY0z9BQgv_caq9651g-OLs/edit?usp=sharing

[mhdawson]

@benjamingr can you send me an invite to the meeting as well?

[mhdawson]

Nevermind I see I'm too late from the doodle.

[benjamingr]

Hey sorry @mhdawson the meeting just happened the minutes are here: https://docs.google.com/document/d/1aZzdQbo2G2wpGewxnkXaBoY0z9BQgv_caq9651g-OLs/edit

We can discuss any compelling arguments to change the decision but it was basically:

-We want cancellation to be an exception (on streams in particular) with a .code property.

• AbortError class that doesn’t have to be a DOMException
• just class - AbortError extends Error
• Use .name - AbortError for all cancellations
• .code - `ABORT_ERR`` (just like the DOMException one)
• Let’s not encourage instanceof checks.

I will update the PR at #36048 tomorrow :]

[mhdawson]

@benjamingr thanks for the summary :)