Two ES modules import each other, and one of them top-level awaits a value the other only produces after its own body finishes. What happens when the application loads, and how would you track it down?

## The failure A cycle plus a top-level await can produce a load that never completes. It is worth being precise about why, because the failure mode is unusually unhelpful: nothing is thrown, nothing is rejected, nothing times out. The graph simply stops making progress and the program never starts. ```javascript // a.js import { ready } from './b.js'; const value = await ready; // waits for b.js to finish export const a = value; // b.js import { a } from './a.js'; export const ready = Promise.resolve(a); // resolved only when b's body runs ``` ## Why it locks Evaluation of a module body starts only after its dependencies have finished evaluating, and a top-level await suspends the awaiting module until the awaited promise settles. In a cycle, those two rules can point at each other. One member of the cycle starts evaluating and reaches its top-level `await`. What it is awaiting can only be settled by code in the other member — code that lives after that module's own imports have been satisfied, which means after the first module has finished. So module A is suspended pending a settlement that only B's completed body can produce, and B cannot run to completion because it is downstream of A, which is suspended. Nothing advances. The same shape appears when a module inside a cycle awaits a dynamic import of a module that is currently mid-evaluation in that same cycle: the returned promise settles only when that module finishes evaluating, and it cannot finish while the awaiting module is stuck. ## Why there is no error This is the part worth internalizing. Cycles themselves are legal in ES modules and are handled — the linking phase resolves the bindings and evaluation proceeds through the cycle in a defined order. What the engine does not do is prove that the promises you await will ever settle; that is the halting problem in miniature. A promise that never settles is not an error condition in JavaScript, it is just a promise, so there is nothing for the runtime to report. Contrast this with the failures people expect: a missing export is caught at link time, a throw during evaluation propagates to importers, and even a rejected top-level await produces a real error. A deadlock produces silence. The symptom, then, is absence. In a browser, the module script's evaluation never completes, so nothing that depends on it runs and the page stays as the server sent it. In a server process, startup logging stops partway and the process sits there, alive and idle, often looking to a supervisor like a healthy service that simply never became ready. ## Diagnosing it Because there is no stack, work from the boundary between what ran and what did not. - **Bracket it.** Find the last statement that produced output and the first expected one that did not. The stuck module is at or just above that boundary in the graph. - **Add evaluation markers.** A log at the top of each suspect module's body, plus one immediately after each top-level `await`, immediately shows which module entered and never resumed — a module that logs its start line but never its post-await line is your suspect. - **Look for the cycle.** Once you have the suspended module, check whether anything it awaits is reachable from a module that imports it, directly or through a chain. Cycles are often not visible in one file; a dependency-graph view or a search for imports of the suspect module gets you there faster than reading code. - **Do not expect a timeout to save you.** Wrapping the awaited promise in a timeout turns silence into an error, which is a real improvement for a network operation, but inside a cycle it converts a hang into a startup failure rather than fixing anything. ## Fixing it The reliable fix is to get the await out of the cycle: - **Break the cycle.** Usually the shared thing being passed back and forth belongs in a third module both can import, which removes the mutual dependency entirely. - **Move the async work out of evaluation.** Export an `async` initializer and have a coordinating module call and await it, instead of doing the work during module evaluation. Evaluation ordering then stops being load-bearing. - **Await less.** If the module only needs the value lazily, export a promise or a getter and let consumers await it at the point of use, so no module's evaluation depends on another's completion. The general rule that comes out of this: top-level await is safest in leaf-ish modules with a clean, acyclic set of dependencies. The moment a module participates in a cycle, making its evaluation depend on another module's completion is a hazard, and the failure it produces is one of the least informative in the language.