Async Functions

What Async Functions Actually Change in JavaScript

Async functions are a language-level way to write promise-based code with clearer flow. They still run on the event loop, but they make asynchronous steps read like sequential logic, which reduces callback nesting and makes it easier to compose network calls, timers, file operations, and other non-blocking work.

The key behaviour is not “background execution” in the multithreaded sense. An async function starts synchronously until it reaches an await, then resumes later when the awaited promise settles. That makes the function useful for readable control flow, but it also means any work before the first await still executes immediately on the current thread.

How Promise Settlement and Await Shape Control Flow

An async function always returns a promise, even when the return value looks like a plain value. A returned value becomes a fulfilled promise, while a thrown error becomes a rejected promise. That predictable wrapping is what lets callers use .then(), .catch(), or await consistently.

await pauses only the async function that contains it. It does not block the whole JavaScript runtime. While the function is suspended, other queued work can continue, and once the awaited promise resolves or rejects, execution resumes at the next statement. This is why async functions improve readability without changing the fundamental asynchronous model.

Why Async Functions Matter in Real Code

Async functions are especially useful when a sequence of dependent operations would otherwise become hard to read or maintain. They make it easier to express “do this, wait for that, then continue” without deeply nested callbacks or long promise chains.

They also help standardise error handling. A try/catch block can handle both synchronous failures and awaited promise rejections in one place, which is often simpler than scattering separate error handlers across a chain. The trade-off is that developers still need to think carefully about concurrency, because awaiting one operation at a time can be slower than starting independent work in parallel.

Common Pitfalls and Semantic Edge Cases

Async functions can create subtle bugs when people assume they are equivalent to “making code non-blocking” in every respect. Any CPU-heavy work inside the function still runs synchronously until the function reaches an await point, so long-running computation can still delay the event loop.

Another frequent mistake is overusing await where parallelism is possible. If two independent promises are awaited one after the other, the code becomes easier to read but may also become unnecessarily slow. A separate issue is unhandled rejections, which can arise when returned promises are not properly awaited or caught by the caller.

Risk and Threat Considerations

Async functions themselves are not a security feature, but they can affect how security-sensitive code behaves under load and failure. The main risk is misleading control flow: developers may assume an operation has completed, or assume errors are already handled, when the promise is still pending or has been dropped without observation.

Failure mechanism: Promise rejection paths, forgotten awaits, or serialised asynchronous steps can hide failures, delay validation, or create race conditions around security checks, token handling, or state updates.

Impact: The result can be stale authorization state, missed error handling, inconsistent data processing, or hard-to-diagnose application behaviour that weakens operational reliability and, in security-sensitive paths, can widen exposure.

Practitioner Guidance

What to watch for: Treat async functions as a control-flow tool, not a guarantee of safety or performance. The practical question is whether the awaited step is independent, failure-sensitive, or security-relevant, because that determines whether sequential waiting is correct or whether parallel execution and explicit error handling are needed.

Governance implication: Code review should pay attention to where promises are awaited, where rejections are handled, and where state changes occur before and after suspension points. That is especially important in authentication, authorisation, and other request-handling code where timing and error propagation matter.

Related resources from NHI Mgmt Group

• Should organisations allow AI agents to call privileged MCP functions?
• Why do residency programmes often exempt authentication and control-plane functions?
• How should security teams govern MCP async task handles in production?
• How do MCP async workflows affect zero standing privilege goals?