9. How can you cancel a running thunk or API call?
Cancelling Running Thunks or API Calls in Redux Toolkit
In Redux Toolkit, you can cancel a running thunk or API call using the AbortController API built into JavaScript. The createAsyncThunk function provides an abort signal that can be used to cancel ongoing requests. This is especially useful to prevent memory leaks or unnecessary network activity when a component unmounts or a new request replaces an old one.
- 1
1. Access the Abort Signal: The second argument of createAsyncThunk contains an abort signal that you can pass to fetch or other cancellable APIs.
- 2
2. Use signal in Fetch Request: Include the signal in your fetch call so that it can be aborted when requested.
- 3
3. Trigger Abort: You can abort the thunk manually by calling abort() on the promise returned by dispatch(thunk()).
By using the signal provided by createAsyncThunk, you can cleanly cancel ongoing API requests and prevent unnecessary state updates or side effects in your Redux store.
Scenario Questions
- 1
You have a component that dispatches a createAsyncThunk to fetch user data. The user navigates away before the request finishes. How would you cancel that request using RTK?
- 2
If you dispatch two thunks of the same type back‑to‑back, what does RTK do with the first request, and how can you explicitly cancel it?
- 1
We noticed a long‑running API call started by a thunk keeps running after the user logs out, causing stale data updates. Walk me through how you’d debug this and modify the thunk to cancel on logout.
- 2
When using RTK Query, a component unmounts while a query is in flight. Explain how you’d prevent the response from updating state, and which RTK Query cancellation mechanisms you’d use.
- 1
Our dashboard launches dozens of parallel thunks for real‑time metrics, and we’re seeing memory leaks because cancelled requests aren’t cleaned up. How would you redesign the cancellation strategy at the slice or middleware level to handle bulk aborts efficiently?
- 2
We need a global “Cancel All” button that aborts any pending thunks or RTK Query requests across the app. Describe the architecture you’d use, including any store changes, middleware, or AbortController usage.
- 1
We are migrating a legacy codebase that uses custom promise‑based API calls to RTK Query. The new team wants a consistent cancellation policy that works across micro‑frontends and can be toggled per feature flag. How would you design a cross‑team cancellation framework, considering versioning, testing, and backward compatibility?
- 2
Our organization wants to enforce that no thunk can outlive the component that started it, even in server‑side rendering scenarios. Propose an architectural guideline and tooling support to guarantee this, referencing RTK’s abort semantics and potential custom middleware.
Follow-up Questions
- ❓What happens to the Redux state if the abort occurs after the thunk has already dispatched a fulfilled action?
- ❓How would you test that your cancellation logic works correctly?
- ❓Can you combine cancellation with retry logic, and what pitfalls might arise?