Support AbortController

[jopemachine]

Fixes #1511.

Thanks for this awesome lib! :)

I added signal option for supporting AbortController.

when AbortController.abort is called, throws DOMException in the promise of asPromise.ts.

About tests, I copied, pasted and fixed cancel.ts to abort.ts.

I'd appreciate it if you could let me know if I made any mistakes.

Checklist

• I have read the documentation.
• I have included a pull request description of my changes.
• I have included some tests.
• If it's a new feature, I have included documentation updates in both the README and the types.

[jopemachine]

It seems that DOMException does not exist until Node 17.
Would it be possible to create and throw AbortError subclassing RequestError instead of throwing DOMException?
Or should the API's target be set to node 17 or higher?

[sindresorhus]

See how we did it in sindresorhus/p-retry#59

[sindresorhus]

CI is failing. You may need to just rebase from main branch.

[szmarczak]

I've done some logic changes. Previously the abort signal was only affecting the native HTTP stream, which is incorrect, because it doesn't abort the retry timeout (the request would fail though).

Can you fix the tests please?

[jopemachine]

I've done some logic changes. Previously the abort signal was only affecting the native HTTP stream, which is incorrect, because it doesn't abort the retry timeout (the request would fail though).

Can you fix the tests please?

Thanks for your review and for correcting this.

1. IMHO, I think asPromise's update is still needed to reject the promise correctly and fix tests. I would appreciate your letting me know If I got wrong.

2. I deleted globalRequest.destroy from asPromise since it should be done with this line. Other lines are same with previous's codes.

[szmarczak]

IMHO, I think asPromise's update is still needed to reject the promise correctly

Why do you think so?

[jopemachine]

Why do you think so?

I think the AbortError should be caught in Promise#catch, or try-catch statement.
I think the error emitted through this.destroy cannot be caught.
To catch this, I think reject should be called in gotPromise when aborted.

But I noticed that I can simplify the code using the firstRequest object, so I reverted 723b960, updated asPromise, AbortError.

[szmarczak]

I think the error emitted through this.destroy cannot be caught.
To catch this, I think reject should be called in gotPromise when aborted.

It can be caught. destroy() makes Got's Request stream emit error which is caught here and the promise rejects here.

[jopemachine]

It can be caught. destroy() makes Got's Request stream emit error which is caught here and the promise rejects here.

Thanks for letting me know.
I never noticed that. I think I jumped to the conclusion that the errors had not been caught just since the test failed.
I just reverted the commits, fixed the tests.

[szmarczak]

LGTM. The only concern I have is the use of AbortSignal global. I'm not sure if it breaks when someone uses @types/node v14 in their project.

[sindresorhus]

The only concern I have is the use of AbortSignal global. I'm not sure if it breaks when someone uses @types/node v14 in their project.

I think it would. I suggest we just use any for now with a comment to use AbortSignal when targeting Node.js 16.

[jopemachine]

I think for setting the error code value properly, maybe it would be good to make a new Error class AbortError, which is inherited from RequestError.

And because DOMException is not NodeJS.ErrnoException, I think using DOMException is not possible when generating the AbortError, so the updated code shape looks different from other PRs' ones.

[sindresorhus]

I think for setting the error code value properly, maybe it would be good to make a new Error class AbortError, which is inherited from RequestError.

The intention is that we will change to the native DOMException when we can. I don't think we should inherit from RequestError.

And because DOMException is not NodeJS.ErrnoException, I think using DOMException is not possible when generating the AbortError

Why is it not possible?

[jopemachine]

I'm sorry, I was confused if I should throw a custom error here or native DOMException (when possible).

Why is it not possible?

I thought using DOMException is not possible because I had thought AbortError should inherit RequestError, which is not correct.

[jopemachine]

I think this statement might need to be edited since AbortError doesn't have code and request object.

[sindresorhus]

I think this statement might need to be edited since AbortError doesn't have code and request object.

You can add a sentence below it noting the exception.

[szmarczak]

Instead of cloning error, please set this.code like in errors above.

[jopemachine]

Since error (abortsignal.reason) is optional here, it seems passing error into the second argument of the constructor cause compile error.

// Compile error occurs

// Argument of type 'ErrnoException | undefined' is not assignable to parameter of type 'Partial<ErrnoException & { code?: string | undefined; }>'.
// Type 'undefined' is not assignable to type 'Partial<ErrnoException & { code?: string | undefined; }>'
super('This operation was aborted.', error, request);
this.code = 'ERR_ABORTED';

[szmarczak]

I see, thanks for clarifying. In this case you can just skip this. Like so:

super('This operation was aborted.', {}, request);
this.name = 'AbortError';
this.code = 'ERR_ABORTED';

The reason is user accessible via controller.signal.reason, so I don't think we need to expose it for now. That might be for #1953

[szmarczak]

I don't think we should inherit from RequestError.

Why is that? If we strip error metadata then people won't know which request was aborted except the fact that it was aborted. I'm -1 on this.

[sindresorhus]

Why is that? If we strip error metadata then people won't know which request was aborted except the fact that it was aborted. I'm -1 on this.

That's a good point. I agree it's more important with context than the consistency of using DOMException.

[szmarczak]

Friendly reminder: can you address #2020 (comment) please?

[sindresorhus]

Thanks :)