Timeout Read As Definite Failure

What goes wrong

A timeout, cancellation or lost reply arrives after the other side may already have committed, and the sender treats it as proof that nothing happened: it compensates, rolls back its own state or tells the user 'failed'. If the effect did land, both the effect and the reversal (or the repeat) stand.

Example

The call to the payment provider times out; the shop shows 'payment failed' and the customer pays again — but the first charge had gone through, so they are billed twice.

Not to be confused with

The outcome was never checked against durable state; not a cancellation swallowed and turned into a fallback (Swallowed Cancellation) and not a client that loses its retry key (Forgotten Retry Identity).

Discovered by

@sks24git GitHub

Field notes · 7

@sks24git2026-11-04beat 2 review rounds

A request we gave up on was stamped as answered the moment we quit, but the far side could still process it later. Its refusal then gets cached after our clock says the cache already expired.

Treat a timed-out request as unknown, not as answered. It may still land after you stop waiting.
Delete a branch the defaults can never reach. It only collects bugs.

@sks24git2026-10-31beat 3 review rounds

A switch rolled back on a timed-out write and did not refetch, though the write may have landed on the server. The screen kept the old flag and its alert even claimed the list was reloaded.

Refetch after a timeout, not only after success. No answer does not mean no write.
Let a fresh server value beat a stale local choice. Otherwise other writers stay invisible.

@sks24git2026-10-29beat 1 review round

A paid call goes through the same retry helper as the status polls, so a timeout or a reset after the server took the request sends it again. Each retry starts and bills a second job for one change.

Never retry a call that creates paid work on an unclear failure. Retry only what proves the server never saw it.
Test each retry path by its fault. One green 5xx case hides the reset case.

@sks24git2026-10-29

A retry loop checked whether the lost write had landed, but that check could fail too and abort the loop. The fallback then marked a finished job as failed, the exact outcome the retry existed to prevent.

Make every recovery read survive the outage it recovers from. It runs while the store is still away.
Fence the failure write on the state you must not overwrite. A finished row stays finished.

@sks24git2026-09-06beat 15 review rounds

A promo refusal set the generic 'could not complete' copy while the attempt stayed and a reset button rendered. No test drove terminal-then-unknown, so a sticky flag survived the suite.

Recompute per answer, never accumulate. A flag that only ever turns on will describe the previous response.

@sks24git2026-09-06beat 11 review rounds

Transport errors and 5xx fell into a generic 'transfer failed' message while the attempt was deliberately kept for replay. The user read failure, the client planned a retry, and the two stories contradicted.

Copy must match the outcome class. If the code keeps the key, the words must say the result is unknown, not failed.

@sks24git2026-09-05beat 3 review rounds

Rows were stamped "reported" in their own commit, then the page was sent, then a failed send un-stamped them. A pod killed between the stamp and the send leaves the burst marked reported with nobody paged.

A claim before a network call needs a lease. Reopen it when no confirmed delivery follows within a window.
Record the attempt time, not only the success. A timeout is unknown, not failed.