Solution

You'll build a one-shot gate that stays shut until a set number of things have finished, then lets every waiter through at once.

The problem, in plain English

You kick off three downloads and want to run a final step only after all three finish. You don't care about their order or what they return — only that every one of them is done. A countdown latch tracks exactly that: you tell it how many things to wait for, each finished thing calls countDown(), and anyone who called wait() resumes the instant the last one reports in.

The mental model

Picture a gate held shut by a counter set to count. Every countDown() turns the dial down by one. While the dial is above zero the gate stays shut and everyone who called wait() stands behind it. The instant the dial reaches zero the gate swings open and the whole crowd walks through together — and it never shuts again, so anyone who arrives later walks straight through.

A first attempt

The obvious version just flips a flag the first time something reports in:

function asyncBarrierLatchNaive(count) {
  let open = false; // a plain flag — the count is ignored
  const waiters = [];

  function countDown() {
    open = true; // opens on the very first call
    waiters.forEach((resolve) => resolve());
    waiters.length = 0;
  }

  function wait() {
    if (open) return Promise.resolve();
    return new Promise((resolve) => waiters.push(resolve));
  }

  function remaining() {
    return open ? 0 : count; // jumps straight from count to 0
  }

  return { countDown, wait, remaining };
}

This throws away the one number the problem is about. With a count of 3, the first countDown() flips open to true and releases everyone — but two of your three downloads are still running, so the final step fires too early. And remaining() never shows 2 or 1; it leaps from 3 to 0. A latch has to count the calls, not just remember that one happened.

The working solution

function asyncBarrierLatch(count) {
  let remainingCount = count; // countDown() calls still needed before the gate opens
  const waiters = []; // resolve fns of wait() promises made while still closed

  function countDown() {
    if (remainingCount <= 0) return; // already open — extra calls do nothing
    remainingCount--;
    if (remainingCount === 0) {
      // The latch just opened. Release every parked waiter together.
      const pending = waiters.splice(0); // read and clear the queue in one step
      for (const resolve of pending) resolve();
    }
  }

  function wait() {
    // Already open -> resolve now. Otherwise park until countDown opens the gate.
    if (remainingCount <= 0) return Promise.resolve();
    return new Promise((resolve) => {
      waiters.push(resolve);
    });
  }

  function remaining() {
    return remainingCount; // never negative: countDown stops decrementing at zero
  }

  return { countDown, wait, remaining };
}

module.exports = { asyncBarrierLatch };

The single boolean becomes a counter, remainingCount, and that changes everything. countDown() opens the gate only on the call that drives the counter to exactly zero; the remainingCount <= 0 guard at the top makes every later call a no-op, so the count never drifts below zero and waiters are never released twice. And because a wait() made after the gate is open sees remainingCount <= 0, it returns an already-resolved promise instead of parking a resolver that would never be called. remainingCount and waiters live in the closure — the private scope the returned functions share, see MDN on closures — so all three functions read and write the same counter and the same queue.

Walking through one call

Start with asyncBarrierLatch(3): remainingCount is 3 and waiters is empty. Two callers, X and Y, each call wait(). The counter is above zero, so each gets a fresh pending promise and its resolve is pushed onto waiters — the queue now holds [resolveX, resolveY]. Now the countdowns arrive:

• First countDown() — remainingCount drops to 2. Not zero, so nothing is released.
• Second countDown() — remainingCount drops to 1. Still shut.
• Third countDown() — remainingCount drops to 0. This is the opening call: we splice the two resolvers out of waiters and run them, so X's and Y's promises both resolve with undefined on the same tick.
• A stray fourth countDown() — the guard sees the counter is already 0 and returns at once. The count stays 0; nobody is re-fired.

If a third caller, Z, calls wait() now, it sees the counter is 0 and gets an already-resolved promise — no waiting.

Gotchas

• Opening on the first countDown — a plain boolean flag ignores count and releases everyone after one call. Track a counter and open only when it reaches zero.
• Letting the count go negative — without the remainingCount <= 0 guard, surplus countDown() calls push the counter to -1, -2, and remaining() starts reporting nonsense. Guard at the top so extra calls are no-ops.
• Re-firing waiters — if you release the queue whenever remainingCount <= 0 instead of only on the call that reaches zero, later countDown() calls re-run the loop. Fire once, on the exact transition to zero.
• Forgetting the already-open case in wait() — if wait() always parks a resolver, a call made after the gate opened waits forever, because no future countDown() will drain the queue. Check remainingCount <= 0 first and return Promise.resolve().
• Not clearing the queue — resolving the same resolvers twice is harmless, since a promise settles once, but leaking them keeps references alive. splice(0) reads the pending resolvers and empties the queue in one step.

Going further

• Reusable / cyclic barrier — a countdown latch is single-use; once open it stays open. A cyclic barrier re-arms after each release, so N parties can rendezvous round after round.
• await sugar — since wait() returns a promise, a caller can await latch.wait() inside an async function to pause until the group is ready.
• Timeout or cancel — race wait() against a timeout with Promise.race so a caller can give up if the latch takes too long to open.
• Progress from countDown — some latches have countDown() return the new remaining count so callers can log progress without a separate remaining() call.