Asynchronous Resolvers and Concurrency

Awaiting Happens Inside the Resolver

A resolver may return a value or a promise, and the executor treats both the same: it awaits the promise and uses the settled value for that field. The schema does not care whether Post.author arrives from memory or from a three-hop network call.

const resolvers = {
  Post: {
    title: (post) => post.title,                                     // plain value
    author: (post, _a, ctx) => ctx.dataSources.authors.byId(post.authorId), // promise
  },
};

Two failure shapes are worth separating, because they look identical in review:

// BUG: the async function returns before the work finishes
updateScore: async (post, _a, ctx) => {
  ctx.scores.increment(post.id);   // no await — it may reject after we return
  return post;
};

// CORRECT
updateScore: async (post, _a, ctx) => {
  await ctx.scores.increment(post.id);
  return post;
};

In the buggy version the executor resolves the field immediately. When increment rejects afterward there is no field left to attach the error to, so it surfaces as an unhandled rejection in the process: a log line nobody reads, a crashed worker under some runtimes, and a mutation the client was told succeeded. Awaiting inside the resolver is what puts the failure on the right field.

That same missing await quietly voids ordering promises, since serial root execution only waits on what a resolver returns — see serial execution.

What the executor does with a rejection after it arrives is resolver error propagation.

Parallelism You Get Free, and the Kind You Must Build

Sibling fields in a selection set are independent, so the executor issues them concurrently:

{
  me {                       # three requests in flight together
    name
    cart { items { sku } }
    recommendations { sku }
  }
}

me.name            ──────────────►
me.cart            ──────────────►     total ≈ slowest branch, not the sum
me.recommendations ──────────────►

That parallelism costs nothing and needs no code. What you do not get is concurrency across levels of the tree — the executor cannot call me.cart before me resolves — or concurrency inside one resolver. Both are yours to build, and the classic mistake serializes them with await in a loop:

// one wave per id: 20 round trips end to end
const users = [];
for (const id of userIds) {
  users.push(await ctx.dataSources.users.byId(id));
}

// better: one wave total
const users = await Promise.all(
  userIds.map((id) => ctx.dataSources.users.byId(id))
);

With independent fetches, Promise.all replaces N sequential round trips with a single burst. The failure semantics matter: Promise.all rejects on the first rejection while the other promises are still in flight, which is correct when the field is all-or-nothing. When each item should succeed or fail on its own — a batch import, a list of independent checks — settle them individually:

const settled = await Promise.allSettled(userIds.map((id) => loadUser(id)));
const users = settled.filter((r) => r.status === 'fulfilled').map((r) => r.value);
const failures = settled.filter((r) => r.status === 'rejected').length;

The rule of thumb: siblings fetch in parallel for free; anything inside a single resolver needs an explicit Promise.all (all-or-nothing) or Promise.allSettled (per-item outcomes).

Bounding the Fan-Out

Promise.all over five hundred ids opens five hundred concurrent database or HTTP calls. The dependency sees a thundering herd, the connection pool's ten slots admit a fraction of them, and queueing makes latency worse than the sequential version it replaced. Bound the fan-out instead:

async function mapWithConcurrency(items, limit, fn) {
  const results = new Array(items.length);
  let next = 0;

  async function worker() {
    while (next < items.length) {
      const i = next++;                    // claim an index
      results[i] = await fn(items[i]);     // one in flight per worker
    }
  }

  const workers = Math.min(limit, items.length);
  await Promise.all(Array.from({ length: workers }, worker));
  return results;
}

const users = await mapWithConcurrency(userIds, 8, (id) =>
  ctx.dataSources.users.byId(id)
);

Eight workers keep a steady pipeline instead of a burst: throughput stays high, the pool is not flooded, and results[i] still lines up with items[i].

Choosing the right tool:

Speed is only half the job. A fire-and-forget promise — one started and never awaited — hides both its result and its rejection: the work may still be running when the response ships, and a later failure reaches no field at all. Keep risky calls inside the resolver's await chain, or attach a handler explicitly before returning.

Interview angle: "this resolver takes four seconds, fix it" has three standard moves in order — find the await-in-loop and collapse it with Promise.all, batch repeated lookups with a loader, then bound whatever concurrency you just created. Naming all three shows you have done the whole job rather than the first half.