Two tiny functions that make your async code production-ready: `retry` and `timeout`

The article explains two concise higher-order functions, `retry` and `timeout`, that make async JavaScript code more resilient in production environments. The `retry` function automatically reattempts a failed async operation a specified number of times, while the `timeout` function aborts any operation that exceeds a given time limit. Both functions wrap existing async functions without modifying their internal logic and can be composed together to handle network failures and slow responses.

Every async function you write assumes the network cooperates, the server responds, and the database doesn't hiccup. In production, none of those assumptions hold forever. Here are two higher-order functions — each under 15 lines — that make any async function resilient without touching its internals. The problem You have an async function. Maybe it calls an API, queries a database, or reads a file over the network. js async function fetchUserData userId { const response = await fetch /api/users/${userId} ; return response.json ; } Two things will go wrong eventually: - It will fail intermittently and you'll want to retry it - It will hang indefinitely and you'll want to give up after a deadline You could wrap every function in retry logic and timeout logic inline. Or you could write it once, properly, and wrap any function you want. retry — automatic reattempts on failure export function retry count, callback { return async function ...args { let attempts = 0; let lastError; while attempts <= count { try { return await callback ...args ; } catch err { lastError = err; attempts++; } } throw lastError; }; } How it works retry is a higher-order function — it takes a function and returns a new function with retry behaviour baked in. The original function is untouched. The while attempts <= count condition is deliberate. If count is 3 , the loop runs when attempts is 0, 1, 2, 3 — that's 4 total executions: one initial attempt plus three retries. This matches the natural language meaning of "retry 3 times". On success, return await callback ...args exits immediately — no more iterations. On failure, the error is stored in lastError and attempts increments. Once the loop exhausts all attempts, the last error is rethrown — not a generic new Error 'Max retries reached' , but the actual error the callback produced. Your callers get a meaningful error message, not a wrapper. Usage js const resilientFetch = retry 3, fetchUserData ; // Works exactly like fetchUserData, but retries up to 3 times on failure const user = await resilientFetch 'user 123' ; Why await inside try matters try { return await callback ...args ; // ✓ catches rejected promises } catch err { ... } Without await , a rejected promise escapes the try/catch entirely: try { return callback ...args ; // ✗ returns a pending promise — catch never fires } catch err { ... } await unwraps the promise inside the try block, so rejections are catchable. This is one of the most common async/await mistakes and retry only works correctly because it gets this right. timeout — give up after a deadline export function timeout delay, callback { return async function ...args { const timer = new Promise , reject = setTimeout = reject new Error 'timeout' , delay ; return Promise.race callback ...args , timer ; }; } How it works Promise.race resolves or rejects with whichever promise settles first. This function creates a race between two competitors: - callback ...args — the actual work - timer — a promise that rejects after delay milliseconds If the callback finishes in time, its value wins and timer becomes irrelevant. If delay milliseconds pass first, timer rejects with Error 'timeout' and the callback's eventual result is ignored. Notice the timer promise is constructed with , reject — it never resolves, only rejects. This ensures the timer can never accidentally win the race with a successful value; it can only interrupt with a failure. Usage js const limitedFetch = timeout 5000, fetchUserData ; try { const user = await limitedFetch 'user 123' ; } catch e { if e.message === 'timeout' { console.error 'Request took too long' ; } } Combining them Both functions return async functions with the same signature as their input — which means they compose cleanly. js // Retry up to 3 times, but abandon any single attempt after 5 seconds const resilientFetch = retry 3, timeout 5000, fetchUserData ; await resilientFetch 'user 123' ; Here's what happens on each attempt: - timeout 5000, fetchUserData races the fetch against a 5-second timer - If it times out, timeout rejects with Error 'timeout' - retry catches that rejection, increments attempts, and tries again - After 3 retries all fail, retry rethrows the last error Four attempts, each with a 5-second ceiling, maximum 20 seconds total. All from two composable functions and one line of setup. What makes these worth keeping They don't modify the original function. fetchUserData is unchanged. You can use it with or without retry/timeout anywhere else. They forward arguments transparently. ...args passes everything through — the wrapped function behaves identically to the original from the caller's perspective. They preserve the error. retry rethrows lastError , not a new generic error. timeout rejects with a named Error 'timeout' you can check by message. Callers always know what actually went wrong. They compose. Because both return async functions with matching signatures, you can layer them in any order and they work together without knowing about each other. The pattern Both functions follow the same structure: higherOrderFn config, callback { return async function ...args { // enhanced behaviour around callback ...args } } This is the decorator pattern applied to async functions. You write the enhancement once, and apply it to any async function that needs it — no inheritance, no classes, no modification of the original. Just functions wrapping functions. It's a small pattern. It shows up everywhere once you start looking for it.