Durable Waiting, Not Fake Answers

"Offline isn't a crash. It's a room where your question waits, safely, for the door to open."

Offline Is a State, Not an Error

Most apps model offline as failure: a red banner, a discarded action, a "try again later" that already threw your input away. Pippa Go models it as a normal state of the world. Sometimes the link is there; sometimes it isn't. Neither is exceptional. When you ask a question with no connection, nothing breaks — the question is captured, durable, and marked as waiting. It sits in the outbox exactly as safely as a question asked with full bars; the only difference is that delivery hasn't happened yet.

This reframing matters because how you model offline decides what your code does at the worst moment. Model it as an error and your instinct is to handle the error — often by discarding, retrying blindly, or faking a result. Model it as a state and your instinct is to represent the state — capture, mark pending, wait honestly.

What 'Durable Waiting' Actually Means

Durable waiting is a specific, three-part guarantee:

Durable: the waiting question survives app kills, reboots, and hours offline, because it lives in the outbox, not in memory.
Waiting: its status is honestly pending — not answered, not silently dropped. The UI shows a real "waiting to reach Pippa" state.
Resumable: the instant the link returns, the same durable question delivers itself — no user re-action required.

Put together, the user's mental model becomes trustworthy: "I asked; it's saved; it'll go through when it can." That sentence is only true if all three hold. Drop durability and the question dies on reboot. Drop honesty and the UI lies about being done. Drop resumability and the user has to babysit the send.

The Alternative Is a Quiet Betrayal

The tempting shortcut when offline is to give the user something — a cached answer, a local guess, an optimistic "here's probably what Pippa would say." It feels helpful. It's a betrayal, because the user asked a real question and got a manufactured reply wearing Pippa's face. Durable waiting refuses that trade. It would rather show an honest "waiting" for an hour than a confident falsehood in a second. The next lessons make that refusal precise.

Code

Offline as a state, handled by representing it·typescript

async function ask(turn: PippaGoTurn) {
  await commitLocally(turn);          // captured no matter what
  if (!navigator.onLine) {
    await setStatus(turn.deviceTurnId, "pending"); // honest waiting
    return;                            // NOT an error, NOT a fake answer
  }
  await enqueueForDelivery(turn);
}

// Notice there is no 'else fabricate' branch and no 'throw offlineError'.
// Offline is just the path where the turn waits, durably and visibly.

Exercise

Take an app you use and describe how it behaves when you do something offline. Does it discard your action, fake a result, or capture it and wait honestly? Then rewrite its offline behavior as durable waiting: what would it capture, what status would it show, and when would it resume? Notice how often 'handle the error' quietly means 'lose the work.'

Hint

The tell is whether your action survives a reboot while offline. If it does and shows an honest pending state, that's durable waiting. If it vanishes or gets faked, the app modeled offline as an error instead of a state.