4. What are the lifecycle actions automatically created by createAsyncThunk?
Lifecycle Actions in createAsyncThunk
When you create an async thunk using createAsyncThunk in Redux Toolkit, it automatically generates three distinct action types that represent the lifecycle of an asynchronous operation — pending, fulfilled, and rejected.
- 1
1. pending: Dispatched when the async function is first called. Typically used to set a loading state or show a spinner in the UI.
- 2
2. fulfilled: Dispatched when the async operation completes successfully. The returned data becomes the action’s payload.
- 3
3. rejected: Dispatched when the async operation fails due to an error, timeout, or rejection. Contains the error message for debugging or display.
These lifecycle actions allow developers to handle loading, success, and error states in a predictable and structured way, reducing boilerplate and improving async flow management.
Scenario Questions
0-2 years experience
- 1If you add a createAsyncThunk to fetch a list of users, what actions will Redux Toolkit dispatch automatically, and when?
- 2How would you use the pending, fulfilled, and rejected actions to show a loading spinner and an error message in a component?
- 3What happens if the promise returned by the thunk rejects—what action is dispatched and what data does it contain?
2-5 years experience
- 1A component never displays an error when an API call fails. Walk me through how you would debug this using the lifecycle actions from createAsyncThunk.
- 2You need to cancel an in‑flight request when the user navigates away. How do the pending/fulfilled/rejected actions influence your cancellation strategy?
- 3Why might you see both a pending and a rejected action for the same thunk call, and how would you adjust your slice to avoid duplicate state updates?
5-8 years experience
- 1In a large codebase with many async thunks, how would you create a reusable pattern for handling loading and error state using the pending/fulfilled/rejected actions?
- 2If a thunk’s payload creator dispatches another thunk, explain how the lifecycle actions interact and any race‑condition pitfalls.
- 3When scaling to thousands of concurrent requests, what performance concerns arise from the automatic actions, and how could you mitigate them?
8+ years experience
- 1Your team is migrating from custom thunk middleware to createAsyncThunk across many services. What architectural concerns do the standardized lifecycle actions raise for backward compatibility, logging, and monitoring?
- 2How would you extend the default pending/fulfilled/rejected actions to include correlation IDs for tracing across microservices while keeping the createAsyncThunk API unchanged?
- 3If the company mandates a telemetry event on every lifecycle stage of an async thunk, where would you inject that logic without modifying each thunk definition?
Follow-up Questions
- What does the payload of the rejected action look like?
- How would you unit‑test that the pending action fires before the API call?
- If you needed an extra custom action for a thunk, where would you add it?