Skip to content

Should every failure get another try?

Elevator answer

Retry a 503 or a lost connection. Do not ask the payment policy every five seconds whether a blocked card has reconsidered its life choices.

3 coffee-machine misconceptions

Retry Rita

“Try it three times; maybe the policy changes its mind.”

Retry Rita

“Every timeout is a rejection.”

Platform Priya

“One retry policy should rule all actions.”

The real explanation

Retry belongs to uncertainty: a timeout, 503, rate limit, or connection that may recover. CardBlocked, OutOfStock, and AgeRequirementNotMet are answers. Repeating the question adds load and turns a clear rejection into an operational mystery.

TPF treats that distinction as part of execution semantics. Business steps should return explicit outcomes or rejection signals. Connector and runtime boundaries can apply retry policy to transient technical failure. The resulting telemetry should show whether an item was rejected by the business, failed technically, was retried, or reached a terminal failure path.

The difficult case is uncertainty after an external action. A remote payment may have succeeded even though the response timed out. Retrying without an idempotency key can create a second charge; rejecting immediately can abandon a valid action. The solution is not a universal annotation. It is a boundary contract with stable identifiers, an inquiry or reconciliation path where possible, and a retry policy appropriate to the business consequence.

The trade-off is specificity. Different actions deserve different retry budgets and terminal behavior. TPF gives a shared framework for declaring and operating them; it should not flatten them into one generic resilience ritual.

Trade-offs

TPF gains meaningful failure categories. It gives up a universal retry switch. Teams must decide which outcomes are transient, terminal, or uncertain.

When TPF is not a good fit

If a dependency has no idempotency story and no way to reconcile uncertain outcomes, first solve that boundary contract. A retry framework cannot make an unsafe effect safe.