fix(fetch): respect "abort" event on the request signal #394

JesusTheHun · 2023-07-25T15:35:57Z

This discussion pointed out that fetch request are not aborted if the user abort them using an AbortController.
This PR fixes it.

kettanaito · 2023-08-07T09:15:55Z

src/interceptors/fetch/index.ts

+      const signal = interactiveRequest.signal
+      const rejectWhenRequestAborted = new DeferredPromise<string>()
+
+      signal.addEventListener('abort', () => rejectWhenRequestAborted.reject(signal.reason))


I think we should implement it the way that user-caused aborts are treated as AbortError, as per spec.

If I'm reading this right, if the user aborts the request, we don't have to do anything about that except stop the request listener promise. If that's the case, then we should instead have a race between two promises that resolve.

But this may be more complicated than that. I'm trying to account for user-caused abort events while working on #398 and I could certainly use your opinion on what's the best way to approach this.

We can also use a built-in rejection mechanism .throwIfAborted on the signal (spec).

Perhaps it'd be more semantically correct to do that and handle the thrown AbortError as a special case below.

const resolverResult = await until(async () => { request.signal.throwIfAborted() // the rest of the request listener promises. }) if (resolverResult.error) { if (resolverResult.error instanceof AbortError) { // We know request listener lookup halted due to // the operation being aborted. handleIfNeeded() return } // Handle other exceptions from the request listeners. }

One concern here, as far as I understand, .throwIfAborted() is a one-time action. If the request wasn't aborted by the time this method is called, it will never throw even if the request will be aborted in the future.

I will address your points in the near future but I wanted to let you know that I already have submitted a PR for #398

Edit : see PR #393

@kettanaito Outside of msw realm, when a request is aborted, the request/promise is rejected with a DOMException that have reason set to AbortError. Is there any reason to change this behavior ?

I have updated the PR to use the native error instead of a wrapped error.

Outside of msw realm, when a request is aborted, the request/promise is rejected with a DOMException that have reason set to AbortError. Is there any reason to change this behavior ?

We'd have to look how Undici does this. I doubt they implement a DOMException just for this sake. I'm tempted to say they rely on a regular error with the cause set. I'm not sure where I'm proposing something related to that, please point me to that.

Thanks for championing this further! I will take a look once I have a minute.

@kettanaito it turns out they do : https://github.com/nodejs/undici/blob/main/test/fetch/abort.js#L78

This line of code seems to break for me when I'm not setting an AbortController because signal is null in that case.

This line of code seems to break for me when I'm not setting an AbortController because signal is null in that case.

When no abort signal is has been provided to the intercepted request, one is injected automatically, so the signal cannot be null.
If you are facing any issue, please open one.

…js#397) Co-authored-by: avivasyuta <[email protected]> Co-authored-by: Artem Zakharchenko <[email protected]>

kettanaito · 2023-08-30T09:44:31Z

src/interceptors/fetch/index.test.ts

@@ -0,0 +1,96 @@
+import { DeferredPromise } from '@open-draft/deferred-promise'


I think we should rename this test file to abort-controller.test.ts and move it under test/modules/fetch/compliance where we store all integration tests.

same goes for the test added inside src/interceptors/ClientRequest/index.test.ts I assume ?

We can leave that one be, it doesn't concern itself with request handling but focuses on how the .respondWith() works in the context of the ClientRequest. I think it's fine.

I mean I've added a test abort abortion in this file

src/interceptors/fetch/index.ts

kettanaito · 2023-08-30T09:46:47Z

src/interceptors/fetch/index.ts

-          cause: resolverResult.error,
-        })
-        return Promise.reject(error)
+        return Promise.reject(resolverResult.error)


I believe this is incorrect. I copied the previous behavior from Undici and we must comply by it. Note that the FetchInterceptor is primarily meant for Node, and I trust Undici implement the spec rather faithfully.

I'd suggest we revert this particular change for now because it's not related to the abort controller support. We can discuss it as a separate improvement point, what do you think?

I checked the Undici implementation and there are only two causes of error : abortion and network issue.
Since the abortion error is well defined (specific class and specific error code), we can check the error type and reject accordingly.
If we don't do that, we deviate from production behavior.

I agree, we should do it the same way: handle the two error scenarios separately:

Keep what you've introduced for abort errors.

Revert what was there previously (the TypeError) to handle all the other errors (effectively, network errors).

This is what I've done in my latest commit ;)

Thanks so much for addressing it so quickly! Will give it the last round of review and let's get this published.

kettanaito · 2023-08-30T10:09:57Z

I've updated the tests a little, but what you wrote was really good. The abort controller tests now pass but I think we need to take a look at the test/modules/fetch/fetch-exception.test.ts to see if I got the original intention there wrong.

During my tests with Undici, network errors would result in a TypeError: Failed to fetch where the original thrown exception is set in the cause by Undici (I don't believe that happens in the browser). In other aspects, a network error also results in TypeError in the browser.

Here's the reference: https://github.com/nodejs/undici/blob/111fd2388094270259814ca7ea5da7d07b2126f6/lib/fetch/index.js#L227

Note that Unidici treats response (?) abort and network errors differently:

https://github.com/nodejs/undici/blob/111fd2388094270259814ca7ea5da7d07b2126f6/lib/fetch/index.js#L211-L221

Maybe we should do the same in the resolverResult.error handling.

kettanaito · 2023-08-30T10:11:46Z

src/interceptors/fetch/index.ts

+      const signal = interactiveRequest.signal
+      const requestAbortRejection = new DeferredPromise<string>()
+
+      signal.addEventListener('abort', () => requestAbortRejection.reject())


Should we forward the abort information exposed to this listener, like abort reason and such? It does work without it so I assume the abort controller already exposes that information in the abort error, is that correct?

As in, why this is not needed?

signal.addEventListener('abort', () => { requestAbortRejection.reject(signal.reason) })

🤔

It turns out it does not work.
The reason your test passes is because you abort the request before it starts. If you try the same thing with a pending request, abortError will be undefined.

If the request is aborted, the condition line 73 is not fulfilled, the flow will therefore continue and execute the native request, which will throw because it has been aborted. This is why it looks like it works.

Please also note that the condition line 73 is incorrect : if null is given as a reason, the condition will fails and the flow will continue. While this do not lead to a runtime issue as explained above, I changed the condition to also check if the abortion promise was rejected.

I understand how it affects the promise flow, us using the abort reason as the rejection value and that it may produce false negatives, but my question was about whether we have to respect that reason in any way? As in, forward it directly. We can always reject with an object, or a different data structure to prevent false positives.

reject with the abortion reason or reject with a TypeError

kettanaito · 2023-08-30T14:01:39Z

src/interceptors/fetch/index.ts

@@ -70,10 +70,17 @@ export class FetchInterceptor extends Interceptor<HttpRequestEventMap> {
        return mockedResponse
      })

-      if (resolverResult.error || requestAbortRejection.state === 'rejected') {
+      if (requestAbortRejection.state === 'rejected') {


Do you think we should conceptually treat this promise as resolved instead?

If we imagine promise as an intention, then the intention here is to know when the request has been aborted by another actor. In that light, an aborted request would mean a resolved requestAborted promise.

It would make this check read much nicer as well. What are your thoughts on this?

I'm also a bit hesitant to base this condition on the request abort promise itself. I'd rather we used that promise in the Promise.race() but handled the resolverResult.error differently. This implies that requestAbortRejection can still throw but it does so with a custom error/object that is later checked on the resolverResult.error:

signal.addEventListener('abort', () => { requestAbortRejection.reject({ type: 'aborted', reason: signal.reason }) }) if (resolverResult.error) { if (resolverResult.error.type === 'aborted') { return Promise.reject(resolverResult.error.reason) } return /* create the TypeError, set "cause" */ }

We can also use a custom AbortError class to prevent any false positives here since it's possible for the user to abort a request with a compatible object as the reason.

It is true that the promise encapsulate the expectation of an aborted request.
Resolving it would mean that the expectation has been reached, which is logically correct.
However, in our case, we use a promise as a poor man's event : the promise rejection carries no expectation and therefore no logical meaning. We just want to be notified when the abortion happens.
From there, this promise is a mere async tool.
Resolving it, then check the race winner, then throw a custom object, check the resolverResult resolution value, all of that to ultimately throw the error we had in the first place, seems unnecessary to me.
On a side note, in the end, I'm not the maintainer of the project, if you feel more comfortable with this extra layer, do it, this is your call :)

Thanks for your input. I agree that it's mainly a semantic difference. We can leave it rejecting as-is. On the second half, I will lean toward making the resolver handling more streamlined, handling it by what the until returns instead of relying on external factors like the rejection promise. I will push the change shortly.

Actually my point is that this is not a semantic difference but a technical one. We expect something to happen, using resolve or reject make no difference. If our expectation could fail then it would make a semantic difference.

I ended up leaving the explicit rejection promise check but instead of coupling the request rejection promise and the resolver error, I reject the request promise with the abort rejection reason. Also, that is hell of a sentence to write.

kettanaito · 2023-09-01T18:10:36Z

@JesusTheHun, hi! The changes look great from my side, is there anything else we should consider before publishing this?

kettanaito · 2023-09-01T18:13:41Z

src/interceptors/fetch/index.ts

+        () => {
+          requestAborted.reject(signal.reason)
+        },
+        { once: true }


I've made sure we only react to the abort event once to make sure there's no event emitter memory leak when cloning requests (each request clone will also preserve previously attached listeners, I believe; I recall an issue about this in the past).

kettanaito

This is awesome. Thank you for your contribution, @JesusTheHun! 👏

JesusTheHun · 2023-09-01T19:03:03Z

LGTM 👌 Now #393 😁💪

kettanaito · 2023-09-01T21:02:28Z

There's an issue with the automated releases in this repo, I will look into it and see if I can figure it out before releasing this. If I notice it taking much time, I will release manually but I'd pretty much love to solve the automation issue.

kettanaito · 2023-09-02T11:57:40Z

Released: v0.24.1 🎉

This has been released in v0.24.1!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.

fix: abort request if the user aborts it

52aa901

kettanaito reviewed Aug 7, 2023

View reviewed changes

This was referenced Aug 26, 2023

Native node.js fetch doesn't abort when an msw server is running mswjs/msw#1701

Closed

msw 1.1.0 regresses tests with Testing Library, React and Jest: "The current testing environment is not configured to support act(...)" mswjs/msw#1563

Closed

JesusTheHun and others added 5 commits August 29, 2023 16:47

fix: reject user request with native error instead of wrapper error

d48c61a

docs: fix request typo in readme (mswjs#404)

8e229ca

chore: migrate to pnpm (mswjs#407)

96e1685

fix: set "X-Request-Id" header in XMLHttpRequest only in Node.js (msw…

94a2a59

…js#397) Co-authored-by: avivasyuta <[email protected]> Co-authored-by: Artem Zakharchenko <[email protected]>

Merge branch 'main' into fix/honor-abort-signals

e0ca09d

kettanaito reviewed Aug 30, 2023

View reviewed changes

src/interceptors/fetch/index.ts Show resolved Hide resolved

kettanaito reviewed Aug 30, 2023

View reviewed changes

test: move fetch abort controller compliance test

864a06e

kettanaito reviewed Aug 30, 2023

View reviewed changes

JesusTheHun added 2 commits August 30, 2023 13:23

fix: forward abort reason

faff151

fix: split request rejection logic

4753f13

reject with the abortion reason or reject with a TypeError

kettanaito reviewed Aug 30, 2023

View reviewed changes

kettanaito added 2 commits August 30, 2023 17:14

chore(fetch): reject request with request abort rejection reason

46dd281

Merge branch 'main' into fix/honor-abort-signals

e5818a1

kettanaito changed the title ~~fix: abort request if the user aborts it~~ fix(fetch): abort request if the user aborts it Sep 1, 2023

kettanaito changed the title ~~fix(fetch): abort request if the user aborts it~~ fix(fetch): respect "abort" event on the request signal Sep 1, 2023

kettanaito added 2 commits September 1, 2023 20:10

Merge branch 'main' into fix/honor-abort-signals

f57fcf9

fix: listen to "abort" event once

b5e4db9

kettanaito reviewed Sep 1, 2023

View reviewed changes

chore: remove log from test

5470be2

kettanaito approved these changes Sep 1, 2023

View reviewed changes

kettanaito added the release candidate label Sep 1, 2023

Merge branch 'main' into fix/honor-abort-signals

25ad663

kettanaito merged commit 33dcbe0 into mswjs:main Sep 2, 2023
1 check passed

kettanaito mentioned this pull request Sep 23, 2023

Should we run interceptor handler for destroyed(/aborted) requests? #444

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(fetch): respect "abort" event on the request signal #394

fix(fetch): respect "abort" event on the request signal #394

JesusTheHun commented Jul 25, 2023

kettanaito Aug 7, 2023

kettanaito Aug 7, 2023 •

edited

Loading

JesusTheHun Aug 7, 2023 •

edited

Loading

JesusTheHun Aug 29, 2023

JesusTheHun Aug 29, 2023

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

sag-tobias-frey Jan 10, 2024

JesusTheHun Jan 10, 2024

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

kettanaito commented Aug 30, 2023

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

kettanaito Aug 30, 2023 •

edited

Loading

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

JesusTheHun Aug 30, 2023

kettanaito Aug 30, 2023

kettanaito commented Sep 1, 2023

kettanaito Sep 1, 2023

kettanaito left a comment

JesusTheHun commented Sep 1, 2023 •

edited

Loading

kettanaito commented Sep 1, 2023

kettanaito commented Sep 2, 2023

		@@ -0,0 +1,96 @@
		import { DeferredPromise } from '@open-draft/deferred-promise'

fix(fetch): respect "abort" event on the request signal #394

fix(fetch): respect "abort" event on the request signal #394

Conversation

JesusTheHun commented Jul 25, 2023

Choose a reason for hiding this comment

kettanaito Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

JesusTheHun Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kettanaito commented Aug 30, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kettanaito Aug 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kettanaito commented Sep 1, 2023

Choose a reason for hiding this comment

kettanaito left a comment

Choose a reason for hiding this comment

JesusTheHun commented Sep 1, 2023 • edited Loading

kettanaito commented Sep 1, 2023

kettanaito commented Sep 2, 2023

Released: v0.24.1 🎉

kettanaito Aug 7, 2023 •

edited

Loading

JesusTheHun Aug 7, 2023 •

edited

Loading

kettanaito Aug 30, 2023 •

edited

Loading

JesusTheHun commented Sep 1, 2023 •

edited

Loading