Fix AbortError being triggered incorrectly on createApi endpoint timeout

[andrejpavlovic]

This PR:

• Fixes bug where a timeout triggered on createApi endpoint would return a generic AbortError instead of TIMEOUT_ERROR.
• Adds a testcase for that validates this behavior.
• Resolves Timeout not throwing error with status TIMEOUT_ERROR #2915

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[netlify]

✅ Deploy Preview for redux-starter-kit-docs ready!

Name	Link
🔨 Latest commit	d9a9106
🔍 Latest deploy log	https://app.netlify.com/sites/redux-starter-kit-docs/deploys/66eb952228af7b0009923d8d
😎 Deploy Preview	https://deploy-preview-4628--redux-starter-kit-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit d9a9106:

Sandbox	Source
@examples-query-react/basic	Configuration
@examples-query-react/advanced	Configuration
@examples-action-listener/counter	Configuration
rtk-esm-cra	Configuration

[phryneas]

Could you please explain the reasoning here a bit? It's not immediately obvious to me.

[andrejpavlovic]

Could you please explain the reasoning here a bit? It's not immediately obvious to me.

Sure thing! As I alluded to in #2915, the issue exists because of a bit of a race condition happening.

1. When fetchBaseQuery times out, it triggers api.abort() on global abort controller (ie. on the one that is created inside createAsyncTrunk)
   

   redux-toolkit/packages/toolkit/src/query/fetchBaseQuery.ts

   Lines 276 to 279 in bc0bf0f

   	setTimeout(() => {
   	timedOut = true
   	api.abort()
   	}, timeout)

2. That in turns rejects the abortPromise in createAsyncTrunk with the generic AbortError.
   

   redux-toolkit/packages/toolkit/src/createAsyncThunk.ts

   Lines 604 to 610 in bc0bf0f

   	const abortedPromise = new Promise<never>((_, reject) => {
   	abortHandler = () => {
   	reject({
   	name: 'AbortError',
   	message: abortReason || 'Aborted',
   	})
   	}

3. Which then rejects the Promise.race promise here:
   

   redux-toolkit/packages/toolkit/src/createAsyncThunk.ts

   Lines 623 to 626 in bc0bf0f

   	finalAction = await Promise.race([
   	abortedPromise,
   	Promise.resolve(
   	payloadCreator(arg, {

4. And this rejection (the generic AbortError) gets returned by the createAsyncTrunk here:
   

   redux-toolkit/packages/toolkit/src/createAsyncThunk.ts

   Lines 654 to 657 in bc0bf0f

   	finalAction =
   	err instanceof RejectWithValue
   	? rejected(null, requestId, arg, err.payload, err.meta)
   	: rejected(err as any, requestId, arg)

So even though fetchBaseQuery would resolve to TIMEOUT_ERROR (see below), it wouldn't matter, because the global abortPromise would always resolve first.

redux-toolkit/packages/toolkit/src/query/fetchBaseQuery.ts

Lines 282 to 286 in bc0bf0f

	} catch (e) {
	return {
	error: {
	status: timedOut ? 'TIMEOUT_ERROR' : 'FETCH_ERROR',
	error: String(e),

Since fetchBaseQuery is quite capable of resolving the timeout locally, there is no need to trigger the global abort inside of it.

The solution I applied was to create an AbortController inside of fetchBaseQuery that would handle the timeout locally, but would also abort if abort is triggered on the global signal:

redux-toolkit/packages/toolkit/src/query/fetchBaseQuery.ts

Lines 228 to 233 in d9a9106

	let abortController: AbortController | undefined, signal = api.signal
	if (timeout) {
	abortController = new AbortController()
	api.signal.addEventListener('abort', abortController.abort)
	signal = abortController.signal
	}

To sum it up, in this PR, we avoid the race condition in createAsyncThunk between 1. triggering global abort and 2. handling the timeout in fetchBaseQuery, by never triggering the global abort on timeout in the first place.

Of note: As far as I understand best practices for using AbortController, abort callback should not be passed to fetchBaseQuery in the first place, just the signal. I would go as far as suggest to remove passing this parameter:

redux-toolkit/packages/toolkit/src/createAsyncThunk.ts

Line 632 in bc0bf0f

abort,

[phryneas]

I see, thank you for the explanation.

It's a shame that AbortSignal.any is so new that we probably can't use it, or otherwise we could have done something much shorter like

diff --git a/packages/toolkit/src/query/fetchBaseQuery.ts b/packages/toolkit/src/query/fetchBaseQuery.ts
index 9dc14d97..f2a3b732 100644
--- a/packages/toolkit/src/query/fetchBaseQuery.ts
+++ b/packages/toolkit/src/query/fetchBaseQuery.ts
@@ -225,12 +225,8 @@ export function fetchBaseQuery({
       ...rest
     } = typeof arg == 'string' ? { url: arg } : arg

-    let abortController: AbortController | undefined, signal = api.signal
-    if (timeout) {
-      abortController = new AbortController()
-      api.signal.addEventListener('abort', abortController.abort)
-      signal = abortController.signal
-    }
+    const timeoutSignal = timeout ? AbortSignal.timeout(timeout) : undefined
+    const signal = timeoutSignal ? AbortSignal.any(api.signal, timeoutSignal) : api.signal

     let config: RequestInit = {
       ...baseFetchOptions,
@@ -277,27 +273,17 @@ export function fetchBaseQuery({
     const requestClone = new Request(url, config)
     meta = { request: requestClone }

-    let response,
-      timedOut = false,
-      timeoutId =
-        abortController &&
-        setTimeout(() => {
-          timedOut = true
-          abortController!.abort()
-        }, timeout)
+    let response
     try {
       response = await fetchFn(request)
     } catch (e) {
       return {
         error: {
-          status: timedOut ? 'TIMEOUT_ERROR' : 'FETCH_ERROR',
+          status: timeoutSignal?.aborted ? 'TIMEOUT_ERROR' : 'FETCH_ERROR',
           error: String(e),
         },
         meta,
       }
-    } finally {
-      if (timeoutId) clearTimeout(timeoutId)
-      abortController?.signal.removeEventListener('abort', abortController.abort)
     }
     const responseClone = response.clone()

[phryneas]

Looks good to me :)

[andrejpavlovic]

I see, thank you for the explanation.

It's a shame that AbortSignal.any is so new that we probably can't use it, or otherwise we could have done something much shorter like

diff --git a/packages/toolkit/src/query/fetchBaseQuery.ts b/packages/toolkit/src/query/fetchBaseQuery.ts
index 9dc14d97..f2a3b732 100644
--- a/packages/toolkit/src/query/fetchBaseQuery.ts
+++ b/packages/toolkit/src/query/fetchBaseQuery.ts
@@ -225,12 +225,8 @@ export function fetchBaseQuery({
       ...rest
     } = typeof arg == 'string' ? { url: arg } : arg

-    let abortController: AbortController | undefined, signal = api.signal
-    if (timeout) {
-      abortController = new AbortController()
-      api.signal.addEventListener('abort', abortController.abort)
-      signal = abortController.signal
-    }
+    const timeoutSignal = timeout ? AbortSignal.timeout(timeout) : undefined
+    const signal = timeoutSignal ? AbortSignal.any(api.signal, timeoutSignal) : api.signal

     let config: RequestInit = {
       ...baseFetchOptions,
@@ -277,27 +273,17 @@ export function fetchBaseQuery({
     const requestClone = new Request(url, config)
     meta = { request: requestClone }

-    let response,
-      timedOut = false,
-      timeoutId =
-        abortController &&
-        setTimeout(() => {
-          timedOut = true
-          abortController!.abort()
-        }, timeout)
+    let response
     try {
       response = await fetchFn(request)
     } catch (e) {
       return {
         error: {
-          status: timedOut ? 'TIMEOUT_ERROR' : 'FETCH_ERROR',
+          status: timeoutSignal?.aborted ? 'TIMEOUT_ERROR' : 'FETCH_ERROR',
           error: String(e),
         },
         meta,
       }
-    } finally {
-      if (timeoutId) clearTimeout(timeoutId)
-      abortController?.signal.removeEventListener('abort', abortController.abort)
     }
     const responseClone = response.clone()

Ah, yes, that's a thing of beauty!

[EskiMojo14]

thanks!