THE FOLD / GLITCH / HEISENBUG / THE PARTIAL FAILURE
THE PARTIAL FAILURE
it makes the unknown harmless, not known
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A remote call has three outcomes, not two. It worked, it did not happen, or — the one nobody designs for — it happened and the answer was lost. From the caller those last two look identical.
LIT verified live. 100,000 calls: 94,039 succeeded, 2,965 cleanly failed before arriving, and 2,996 arrived and lost their reply — 3.00% in a state the caller cannot distinguish. Only the 2,965 are safe to retry blindly. Retrying the other 2,996 duplicates real work. With an idempotency key all 100,000 become safe, because the question changes from “did it happen” to “has this one happened”.
LIT verified live. 100,000 calls: 94,039 succeeded, 2,965 cleanly failed before arriving, and 2,996 arrived and lost their reply — 3.00% in a state the caller cannot distinguish. Only the 2,965 are safe to retry blindly. Retrying the other 2,996 duplicates real work. With an idempotency key all 100,000 become safe, because the question changes from “did it happen” to “has this one happened”.
2 HOW IT WAS WEAVED · AI + HUMAN
The three-outcome problem is why every payments API has an idempotency key and why “at least once” is the only delivery guarantee most systems can actually offer.
AVAN (AI) counted the buckets separately rather than reporting a success rate. 94% succeeded is the number that gets published; 3% unknown is the number that decides your architecture, and averaging them into “97% did not fail” hides exactly the population that needs the design work.
AVAN (AI) counted the buckets separately rather than reporting a success rate. 94% succeeded is the number that gets published; 3% unknown is the number that decides your architecture, and averaging them into “97% did not fail” hides exactly the population that needs the design work.
3 ONE DIMENSION
Three outcomes, and which two the caller can tell apart.
4 TWO DIMENSIONS · INTERACTIVE
Retry, and watch the duplicates arrive.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: a question with no answer coming.
AVAN’s addition (the inverse-companion): the forward reading is that partial failure is a hard case to handle. The inverse is that it is the only case, and the other two are conveniences. Success and clean failure are both just partial failure where the evidence happened to survive; nothing about the network promised you that evidence. Read backwards, an idempotency key does not solve the unknown — it makes the unknown harmless, which is the only kind of solution available when the fact you need is genuinely not in your possession.
LIT 100,000 calls give 94,039 successes, 2,965 clean failures that never arrived, and 2,996 that arrived and lost their reply - 3.00% in a state the caller cannot distinguish - so only the 2,965 are safe to retry blindly while retrying the other 2,996 duplicates real work, and an idempotency key makes all 100,000 safe
FIG The three-outcome problem is why every payments API has an idempotency key and why at-least-once is the only delivery guarantee most systems can offer. AVAN counted the buckets separately rather than reporting a success rate: 94% succeeded is the number that gets published, 3% unknown is the number that decides your architecture, and averaging them into 97% did not fail hides exactly the population that needs the design work.
FIG The three-outcome problem is why every payments API has an idempotency key and why at-least-once is the only delivery guarantee most systems can offer. AVAN counted the buckets separately rather than reporting a success rate: 94% succeeded is the number that gets published, 3% unknown is the number that decides your architecture, and averaging them into 97% did not fail hides exactly the population that needs the design work.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of HEISENBUG · David Lee Wise (ROOT0), with AVAN