← deemwar engineering examples Runnable · Node · zero deps · free

Your send() said "sent" — and the message never arrived.

Many messaging protocols ack in two steps: a fast "accepted, here's your message id" ack, followed later by a second, asynchronous ack that says whether it was actually delivered — or rejected. A send() that resolves on the first ack is right for the common case and silently wrong for every case where the second ack is the one that mattered.

The crux

function naiveSend(transport, id) {
  return new Promise((resolve) => {
    transport.bus.once('ack', (ack) => {
      resolve({ sent: true, stage: ack.stage }); // "sent: true" no matter what stage this was
    });
    transport.send(id);
  });
}

The bug isn't in the promise, the event bus, or the transport — it's that sent: true is returned on the first ack the code happens to see, not the ack that actually settles the question. The queued ack and the terminal (delivered/rejected) ack look identical to code that isn't checking which one it got.

Run it

node check.js --demo

Zero dependencies, no network — a real event stream (Node's built-in EventEmitter) fires a fast "queued" ack, then an asynchronous "rejected" ack for the same message id, and two implementations race to answer "did it send."

$ node check.js --demo Scenario: the transport queues the message fast, then asynchronously rejects it (blocked recipient / policy violation / expired session). Naive send() result: {"sent":true,"stage":"queued"} Fixed send() result: REJECTED -- send rejected: rejected DIAGNOSIS: the naive send() reported "sent: true" for a message that was actually rejected -- because it resolved on the first ack (queued) instead of waiting for the terminal one (rejected). Every caller, log line, and retry decision built on that result believes the message went out. It did not.

The fix

Correlate acks by message id, and know the difference between a provisional ack (queued/accepted) and a terminal one (delivered/rejected/failed) — don't resolve on the first thing that arrives with the right id.
Give the terminal ack a timeout, not an indefinite wait — if it never comes, that's its own failure mode worth surfacing, not silence.
Log which stage a "success" actually settled on. If your logs can't answer that, you can't tell this bug apart from a real success after the fact.

Seen in the wild

This is the same shape flagged in a real WhatsApp automation thread we've engaged with directly: an account-class enforcement issue where the client-visible signals all looked fine (socket connects, message accepted) right up until an out-of-band signal — invisible to the naive send path — was the one that actually mattered. The specific trigger differs by protocol and platform; the shape — a fast provisional ack mistaken for the real answer — repeats across messaging integrations generally.

Get the code

Source on GitHub