Redux Toolkit 2.0 createAsyncThunk abort signal: Should loading state reset automatically?

Question

When using Redux Toolkit 2.0's createAsyncThunk with an AbortSignal, the thrown AbortError is transformed into a rejected action whose error.message is set to "Aborted". The library does not automatically reset loading flags or other UI state tied to the request, leaving it to developers to dispatch a separate cleanup action or to interpret the rejected action's metadata.
This design choice creates variability across codebases: some teams manually clear state in a reducer, others rely on the rejected action, and a few forget to handle aborts altogether. The unresolved question is whether a future version should provide a built‑in helper (e.g., an abortReducer) that automatically clears loading state on abort, or retain the manual approach to preserve flexibility for custom side‑effects and middleware.
Should Redux Toolkit ship an automatic loading‑state reset for aborted thunks? What impact would such a helper have on existing reducers, middleware chains, and upgrade paths? How could the library version the change to avoid breaking current implementations that depend on the current manual handling?

Zoha · Answer

Direct answerAs of Redux Toolkit 2.0, createAsyncThunk with an AbortSignal dispatches a rejected action where error.message is set to Aborted, but the loading state flag is not automatically cleared. The library leaves this responsibility to the developer, either through a manual cleanup reducer or by interpreting the rejected action's metadata.Likely explanation vs confirmed factsLikely explanation: The thunk's internal fulfillment logic transforms an AbortError into a rejected promise, and Redux Toolkit's action creators do not include a built-in loading-state mutation.Confirmed fact (from research): Dispatching an aborted thunk preserves the loading flag unless a separate reducer or middleware explicitly clears it.Steps to verify current behaviorDispatch a createAsyncThunk with an AbortSignal that is aborted before the async operation resolves.Inspect the store state with store.getState() or Redux DevTools.Confirm that the loading flag associated with the thunk remains active unless a cleanup action has been dispatched.Verify the rejected action's error.message equals Aborted.Consideration for automatic loading‑state resetAn automatic reset would intercept rejected actions with error.message=Aborted and mutate UI state, but this could conflict with reducers that intentionally preserve loading context or perform side‑effects on abort. A versioned opt‑in mechanism—such as a dedicated reducer helper or a createAsyncThunk option—would allow gradual migration without forcing changes on existing implementations.A diagnostic detail that could refine the recommendation: does your middleware or root reducer intercept rejected async actions before they reach your UI loading reducer?

Redux Toolkit 2.0 createAsyncThunk abort signal: Should loading state reset automatically?

1 answer

Direct answer

Likely explanation vs confirmed facts

Steps to verify current behavior

Consideration for automatic loading‑state reset

Your perspective belongs here.

0 question comments