A module caches the promise returned by its initialisation function in a module-level variable so that concurrent callers share one in-flight request. The very first attempt rejects, and from then on every caller in the process gets the identical failure with no further network activity. Explain what the promise lifecycle is doing here, and how you would fix it.

## What the cache actually holds The pattern looks like textbook memoisation: ```js let cached = null; function getConfig() { if (cached === null) cached = loadConfigFromServer(); return cached; } ``` On the success path this is genuinely good: ten callers during startup all get the same promise, one request goes out, and everyone shares the result. It works because of the two properties this leaf is about — a promise is eager, so the work is already running by the time the second caller arrives, and a settled promise replays its outcome to any number of late subscribers. The problem is that both properties apply just as strongly to failure. When `loadConfigFromServer()` rejects, `cached` now holds a *rejected* promise. Settlement is one-way and one-time: there is no path from rejected back to pending, and nothing about subscribing re-runs the underlying work. Every subsequent `getConfig()` returns that same object, and every subscriber gets the same reason instantly. A momentary DNS blip during boot has become a permanent, process-lifetime outage. ## Why no retry happens "for free" Candidates often expect a rejected promise to retry when re-awaited, by analogy with lazy abstractions where the object is a recipe. In JavaScript the object is a receipt. Awaiting it a second time performs no work at all; it reads a stored value. The only way to attempt the operation again is to call the function that constructs a promise again — which is precisely what the `if (cached === null)` guard now prevents. ## Diagnosing it in production The signature is distinctive and worth recognising: a service that fails every request with the *same* error message and the same stack, with zero outbound calls to the dependency, while the dependency itself is demonstrably healthy. Restarting the process fixes it, which is the tell that the bad state lives in memory rather than in the dependency. Retry-on-failure at the HTTP layer will not help either, because the failure is served from memory long before any transport is involved. ## Fixing it: evict on rejection The minimal fix keeps the deduplication benefit and removes the poisoning: ```js let cached = null; function getConfig() { if (cached === null) { cached = loadConfigFromServer().catch((err) => { cached = null; // let the next caller start a fresh attempt throw err; // still reject this caller }); } return cached; } ``` Note both halves. Clearing the variable restores retryability. Rethrowing is essential — a rejection handler that does not rethrow *recovers*, so the callers already waiting would silently receive a fulfilled promise with `undefined` instead of an error. Callers that are already awaiting the poisoned promise still get the rejection: their subscription is to an object that has already settled and cannot be changed. Eviction only affects who arrives afterwards. That is the correct semantics — you cannot retroactively repair an answer you have already handed out. ## The wider design point This is one instance of a general rule that follows from settle-once immutability: **cache promises for deduplication, but cache only successes.** Concretely: - Store the promise while it is pending so concurrent callers share the in-flight work. - On fulfilment, keeping it is fine and is the whole point. - On rejection, evict — the entry represents an attempt that failed, and attempts are not results. If you want more than one-shot retryability, the state you keep should be the *function*, plus policy around it: attempt counters, a backoff delay before the slot becomes eligible again, or a circuit breaker so that a genuinely dead dependency does not attract a stampede of simultaneous retries the instant you clear the cache. That last point matters at scale: naive eviction can convert one shared failure into N concurrent retries, since every waiting caller now finds an empty slot. ## A related variant to watch for The same bug appears without an explicit cache whenever a promise is created once at module scope: ```js export const ready = connect(); // runs at import time, settles once, forever ``` Here the promise is created during module evaluation, and any consumer importing `ready` after a failed connection observes the identical rejection with no chance of a retry. Exporting `connect` — or a `getReady()` accessor with eviction — keeps the retry decision in the caller's hands, which is where it belongs.