Promise states: pending, fulfilled, rejected

Games are played by post over months. The tournament secretary keeps one result card per game.

At the secretary's desk	In the code
a new game's card reads "in play"	pending (step 1)
the secretary inks "won" or "lost" on it	fulfilled or rejected: settled (step 2)
a later letter claiming another result is filed unread; nobody is told it was refused	later calls ignored, silently (step 3)
"this game's result follows the playoff": the card is committed but still reads "in play", and may end "lost"	resolve(thenable): resolved, still pending (steps 4–5)
the playoff's own letters count only the first time too	a fresh once-only pair (step 6)
a club asking about an inked result gets it in the next bulletin, never read out mid-sentence	reaction queued, never inside then (step 7)
every club that asks, early or late, gets the same inked result	the settled value is kept (step 8)

In real terms: a promise records one outcome; the first resolve or reject decides it, and every reaction later receives that outcome.

Breaks down when: a secretary can correct a clerical error; a promise has no correction. Wrong inference: "the secretary may accept a better-attested result later." Nothing ever does.

Contrasting case: a club noticeboard where each new notice covers the last. Many values over time are an event stream or a variable, not one promise.

States are read with Node's util.inspect, shown as pending, fulfilled: … or rejected: … (lib/util.mjs, pro tip 1).

4.1 ExamHall: one promise per attempt

EXH-1800: tiles showed error: timeout for candidates who were online, because the client's internal retry called the same callback a second time. MR !2000 turns that retry off and retries with a new promise.

function getStatus(id) {
  return new Promise((resolve, reject) => {
    feed.status(id, { retries: 0 }, (err, status) => (err ? reject(err) : resolve(status)));
  });
}
const a1 = getStatus('c-114');               // the feed answers each call once, 200 ms later (virtual clock)
a1.then(undefined, (e) => tile.push(`retrying after ${e.message}`));
const a2 = getStatus('c-114');               // created after a1 has settled

t=0  attempt 1 created:        pending
t=200  attempt 1 after its answer: rejected: Error: timeout
t=200  attempt 2 created:        pending
t=400  attempt 2 after its answer: fulfilled: 'online'
t=400  attempt 1 still:          rejected: Error: timeout
tile log: retrying after timeout · tile: online

Each attempt starts pending and settles once (steps 1–3). Attempt 1 stays rejected for good, so a retry needs a new promise.

4.2 Proof domain, catalog: a price SDK's thenable

const price = new Promise((resolve) => {
  resolve(priceSdk.quote('LMP-39'));         // an object with then(), which calls onFail
  log.push('executor returned');
});

right after the executor: pending
after the jobs ran:       rejected: Error: no price for LMP-39
log: executor returned · sdk then() called · price hidden: no price for LMP-39

resolve was called, yet the promise is still pending: resolved is not fulfilled (step 4). The SDK's then runs only after the executor returns, and the promise ends rejected (steps 5–6).

4.3 ExamHall: tiles that attach late

The console's connected promise settled at startup; three tiles attach reactions afterwards.

const connected = Promise.resolve('wss-eu-1');
let seen = 0;
for (const tile of ['c-201', 'c-202', 'c-203']) connected.then((url) => { seen++; console.log(`${tile} sees ${url}`); });
console.log(`after the loop: seen = ${seen}`);

after the loop: seen = 0
c-201 sees wss-eu-1
c-202 sees wss-eu-1
c-203 sees wss-eu-1
after the jobs ran: seen = 3

No reaction ran inside its then call (step 7), and every tile received the same value (step 8). Their order against other queued jobs belongs to the event-loop lesson.