How can I handle fetch request cancellation and timeouts gracefully in an Expo app using AbortController?

Answer the question first

In a functional Expo component you can create a single AbortController per request, pass its signal to fetch, start a setTimeout that calls controller.abort(), and clear that timer in the finally block or the effect cleanup. The fetch promise will reject with an AbortError if the request is aborted, allowing you to distinguish it from other network errors.

Why this pattern works

• Single source of truth: one controller per request guarantees that aborting only happens once.
• Deterministic cleanup: the finally block ensures the timeout is cleared regardless of success, failure, or abort.
• No duplicate aborts: because the controller is stored in a ref and only the timer or component unmount triggers abort(), the request can’t be aborted twice.
• Clear error handling: AbortError.name === 'AbortError' lets you skip state updates when the component is gone.

Step‑by‑step implementation

1. Define a helper that returns a promise and a cancel function.

   function useCancelableFetch(url, options = {}, timeoutMs = 0) {
     const controller = new AbortController();
     const signal = controller.signal;
     let timer;
   
     const fetchPromise = fetch(url, { ...options, signal })
       .then(async res => {
         if (!res.ok) throw new Error(`HTTP ${res.status}`);
         return await res.json();
       });
   
     if (timeoutMs > 0) {
       timer = setTimeout(() => controller.abort(), timeoutMs);
     }
   
     const cancel = () => {
       controller.abort();
       if (timer) clearTimeout(timer);
     };
   
     const wrapped = fetchPromise
       .finally(() => {
         if (timer) clearTimeout(timer);
       });
   
     return [wrapped, cancel];
   }
   

2. Use it inside a component.

   import React, { useEffect, useState, useRef } from 'react';
   import { Text, ActivityIndicator, View } from 'react-native';
   
   export default function DataScreen() {
     const [data, setData] = useState(null);
     const [error, setError] = useState(null);
     const [loading, setLoading] = useState(true);
     const cancelRef = useRef(null);
   
     useEffect(() => {
       const [promise, cancel] = useCancelableFetch(
         'https://api.example.com/items',
         {},
         5000 // 5‑second timeout
       );
       cancelRef.current = cancel;
   
       promise
         .then(setData)
         .catch(err => {
           if (err.name === 'AbortError') {
             console.log('Request aborted');
           } else {
             setError(err.message);
           }
         })
         .finally(() => setLoading(false));
   
       return () => {
         // Component unmount: abort any in‑flight request
         cancelRef.current?.();
       };
     }, []);
   
     if (loading) return ;
     if (error) return {error};
     return {/* render data */};
   }
   

3. Test the abort flow.
   • Navigate away before 5 seconds – the console should log “Request aborted” and the timer should be cleared.
   • Let the request finish – data should render and no abort log appears.
   • Manually trigger cancelRef.current() (e.g., with a button) – the promise rejects immediately with AbortError.

Handling race conditions

Because finally runs after both success and failure, the timer is always cleared. The controller is only aborted once: either by the timer or by component unmount. If the server ignores the abort signal, the underlying TCP connection may still linger until the OS times out, but the UI will no longer update because the component has been removed.

Edge‑case checklist

• Confirm your Expo SDK version supports AbortController (SDK 48+ is safe).
• Keep timeout values reasonable; overly short timeouts can abort legitimate requests.
• Always clear the timeout in finally or the cleanup function to avoid memory leaks.
• Use err.name === 'AbortError' to distinguish aborts from network or HTTP errors.
• Test on both iOS and Android simulators/devices to catch platform‑specific networking quirks.

Missing diagnostic detail?

If you experience unexpected aborts on a particular endpoint, check whether the server supports the AbortSignal header or whether the request is being retried by Expo’s networking layer. Provide the endpoint and any retry logic you have in place so we can refine the solution.