In JavaScript, what happens when you `await` something that is not a promise — for example `await 42`, or `await` on a plain object that merely has a `then` method?

## await resolves, it does not require a promise The operand of `await` is passed through the same resolution machinery a promise uses when it is resolved with a value. Two branches exist: - **Not a thenable** — any primitive, or an object with no callable `then`. The result of the `await` expression is that value, unchanged. - **A thenable** — an object or function with a callable `then` property. Its `then` is invoked with a resolve and a reject function, and the `await` produces whatever that invocation settles with. ```js console.log(typeof (async () => await 42)); // await accepts anything const thenable = { then(resolve) { resolve('from a thenable'); } }; (async () => { console.log(await 42); // 42 console.log(await 'text'); // text console.log(await null); // null console.log(await thenable); // from a thenable })(); ``` ## Suspension still happens The most-missed part: `await 42` is not free and not a no-op. The function suspends at that point and its continuation is queued, exactly as for a real promise. Adding an await for a plain value therefore changes the relative order of your code, which occasionally shows up as an accidental fix or an accidental bug. ## Thenable duck typing is a feature, and a trap Because the check is "does it have a callable `then`", any promise-like object from any library interoperates with `await` without conversion. That interop was a deliberate design choice. The same rule bites when a plain data object accidentally has a `then` method. Since promise *resolution* also applies to values returned from an async function, the object never reaches the caller intact: ```js async function getRecord() { return { id: 1, then(resolve) { resolve('hijacked'); } }; } getRecord().then(v => console.log(v)); // hijacked — the object is gone ``` Worse, a `then` that never calls either callback makes the await hang forever with no error: ```js const blackHole = { then() { /* never settles */ } }; // await blackHole → the function is suspended for the process's lifetime ``` This is a real hazard when awaiting data you did not author — a parsed JSON payload, a user-supplied config object, a module namespace object, or a class instance with a method that happens to be named `then`. The defensive habits are: never name a domain method `then`, and if you must pass through arbitrary data, wrap it (`return { value: data }`) instead of returning it bare from an async function. ## `then` is only honoured once The resolve and reject functions handed to a thenable's `then` are single-shot in effect: the first settlement wins and later calls are ignored. A badly written thenable that resolves twice, or resolves and then throws, cannot corrupt the awaiting function's state — it just gets the first outcome. If the `then` method itself throws before settling, that becomes a rejection, so the await throws. ## Getter hazards The `then` property is read from the value during resolution. If `then` is an accessor with a side effect, that side effect happens simply because the value was awaited or returned from an async function. It is a small but genuine reason to avoid clever getters on objects that cross async boundaries. ## What to say in an interview State the rule in one sentence — `await` resolves its operand, unwrapping anything thenable and passing anything else straight through — then add the two consequences that show depth: the suspension is unconditional, and thenable detection is structural, so an accidental `then` property changes your data's fate.