Promise combinators and concurrency limits

At the counting centre	In the system
Each precinct starts counting its own ballots the moment polls close; the centre only receives returns	Calling upload(n) starts the work; the combinator only watches (step 1)
Certification needs a valid return from every precinct; the first rejected return stops certification at once, without waiting for the rest	all rejects at the first rejection (step 3)
The public report lists every precinct in precinct-number order, with its total or the reason its return was rejected	allSettled: every outcome, in input order (step 4)
The news desk calls the first precinct to report anything, even a rejected return; the analyst waits for the first valid return, and if all are rejected, files the rejections in precinct-number order	race versus any and AggregateError.errors (step 5)
A failed certification sends no one home; every precinct keeps counting	settling cancels nothing (step 6)
The centre has 4 verification teams. A precinct waiting for review gets the next team to finish, whether that team accepted or rejected its last return	the pool keeps k in flight and refills a slot on every settle (step 7)

• Breaks down when: a real election board can order a precinct to stop counting. A promise has no such order, and only work that checks an AbortSignal stops. It also breaks down on a recount: a precinct can report twice, but a promise settles exactly once.
• Contrasting case: a court order that halts every count in the county at the same moment. That is cancellation (AbortController.abort() stopping every fetch that shares the signal), and no combinator ever does it.
• In real terms: a combinator is a new promise whose settle rule reads its inputs' outcomes. It never controls the work behind them.

Example 1: ExamHall, the MR !652 fix for EXH-362. Submit uploads 12 recording chunks, and chunks 5 and 9 fail with 503. The same uploads run three ways on the virtual clock.

const CHUNKS = Array.from({ length: 12 }, (_, i) => i + 1);
const FAILS = new Set([5, 9]);
const durationOf = (n) => 100 + (n % 4) * 50;

function limit(max) {                        // the pool: at most `max` started and unsettled
  let active = 0;
  const queue = [];
  const next = () => {
    if (active >= max || queue.length === 0) return;
    active++;
    const { task, resolve, reject } = queue.shift();
    task().then(resolve, reject).finally(() => { active--; next(); });
  };
  return (task) => new Promise((resolve, reject) => { queue.push({ task, resolve, reject }); next(); });
}
// upload(n): counts in-flight, sleeps durationOf(n), throws `chunk n: 503` for 5 and 9
const report = (rs) => {
  const failed = rs.flatMap((r, i) => (r.status === 'rejected' ? [CHUNKS[i]] : []));
  return `stored ${rs.length - failed.length}/12, retry chunks [${failed.join(', ')}]`;
};

await scenario('all, unbounded',        (upload) => Promise.all(CHUNKS.map(upload)).then(() => 'all stored'));
await scenario('allSettled, unbounded', (upload) => Promise.allSettled(CHUNKS.map(upload)).then(report));
const run3 = limit(3);
await scenario('allSettled, pool of 3', (upload) => Promise.allSettled(CHUNKS.map((n) => run3(() => upload(n)))).then(report));

[all, unbounded] t=150 submit rejected: chunk 5: 503; uploads still running: 7
[all, unbounded] clock drained at t=250; peak in flight 12; uploads finished 12/12
[allSettled, unbounded] t=250 stored 10/12, retry chunks [5, 9]; uploads still running: 0
[allSettled, unbounded] clock drained at t=250; peak in flight 12; uploads finished 12/12
[allSettled, pool of 3] t=750 stored 10/12, retry chunks [5, 9]; uploads still running: 0
[allSettled, pool of 3] clock drained at t=750; peak in flight 3; uploads finished 12/12

Line 1 shows steps 3 and 6: the submit reports failure while 7 uploads are still running, and all 12 finish anyway. Lines 3–6 show steps 4 and 7: allSettled names exactly which chunks to retry, and only the pool keeps the peak at 3. The pool trades time for load: 750 virtual ms against 250.

Each replica sleeps, logs, then returns or throws <name>: 504.

const mixed = { eu: [20, false], us: [60, true], ap: [90, true] };
await scenario('A. race, eu fails first', mixed, (ps) => Promise.race(ps));
await scenario('B. any, same replicas', mixed, (ps) => Promise.any(ps));
await scenario('C. any, all three fail', { eu: [80, false], us: [20, false], ap: [50, false] }, (ps) => Promise.any(ps));

A. race, eu fails first
t=  20    eu failed
t=  20    -> rejected: Error: eu: 504
t=  60    us answered
t=  90    ap answered
B. any, same replicas
t=  20    eu failed
t=  60    us answered
t=  60    -> fulfilled: us price 49.90
t=  90    ap answered
C. any, all three fail
t=  20    us failed
t=  50    ap failed
t=  80    eu failed
t=  80    -> rejected: AggregateError: All promises were rejected | errors: [eu: 504; us: 504; ap: 504]

A and B use the same inputs but settle differently: race takes the first settle and any takes the first success (step 5). In C the replicas fail in the order us, ap, eu, but errors lists them eu, us, ap, which is input order. The message text is V8's; MDN's own example prints a different message, so match on name, never on the message. Both ap answers in A and B still arrive after the decision (step 6).