Orders with the Till Gone — Filling One Hole We Left Open

This magazine wrote the same sentence for six months.

Offline and cache behaviour — no sample ever tested it

(Copied verbatim from Looking Back at January 2026.) This piece deletes that line.

Why it was still there

Not out of laziness. Offline is awkward to test. Testing the connected state is easy — run it and see. Testing the absent state means making it absent, and "absent" comes in several kinds.

This sample covers only the two worst.

1. There is nowhere to send. And the customer is standing in front of you.
2. You sent and no answer came. The pad has no way of knowing whether it arrived.

The two lead to opposite failures. Ignore the first and orders disappear; ignore the second and people are charged twice. Add a queue to solve the first and the second appears — that is what this piece wants to say.

When the till is there

till: connected
online: took 1, delivered 1, till has 1 (3.5k won)

Ordinary. One coffee pressed, the till took it.

The till goes away

till: process gone — the pad is now on its own

We killed the process. For a food truck that is the hotspot dropping, and from the pad's side there is no difference — all that is the same is that what was sent gets no answer.

And three more orders come in.

offline: took pad1-002 (sandwich) — nothing was sent
offline: took pad1-003 (coffee) — nothing was sent
offline: took pad1-004 (juice) — nothing was sent
offline: pad still took 3 orders, 3 waiting, ids pad1-002 pad1-003 pad1-004

The screen is red in order to be honest. Hiding the fact that nothing is going out is not offline support, it is offline concealment. Keep taking orders, but a person has to be able to see how many have not gone.

The outbox is the whole answer

This sample's answer is one class. The order pad never calls the till directly.

/// The order pad never calls the till directly. It writes into here, and here
/// tries to deliver. That one indirection is what lets the person behind the
/// counter keep working while the till is unreachable, and it is also what
/// makes the failure honest: the pad can show how many orders are still
/// undelivered, because the outbox knows.

That one layer gives two things at once. Being able to keep working, and being able to say how many are backed up.

There are only two rules.

① The id is minted here, before the first attempt.

final p = Pending('$device-${(++_minted).toString().padLeft(3, '0')}', item);

If the till assigns the id, a resend becomes a new order. Then the customer is charged twice. For a retry to be safe, what is being retried has to be decided before the retry.

② Send in order, and stop at the first failure.

} catch (_) {
  // Still ours. Leave it at the front and stop — the ones behind it are
  // newer and must not overtake.
  break;
}

Skip ahead and the ledger records the morning wrongly. A ledger where the noon order is stamped before the eleven o'clock one is simply a wrong ledger.

And the queue lives in a file.

/// Where the queue lives between app launches. A queue that only exists in
/// memory is not a queue — closing the lid is the same as losing the orders.
final File spoolFile;