Say whether the failed items already had side effects

What it is

An item marked failed does not automatically mean nothing happened. Money may have moved, mail may be in a queue, a number may be reserved—only the response never arrived, or a later step blew up. Saying whether a failed item already had side effects lets people choose query, wait, fill-in, or edit. Unsaid, failure is treated as “safe to click again.” This entry is about disclosing side effects. It is not about how the status list or the retry button is laid out.

Why it happens

Failure is an observation. A side effect is a record already written in the world. Timeouts, queues, and cross-service calls split the two. Recovery branches entirely on where the split landed: no side effect, edit and submit again; side effect present, forbid the same submit and reconcile; unknown, query first. Disclosure turns the split into a usable sentence: “this one never left,” “this one may have been charged—check first,” “this one was created but the other party was not notified.” Without that sentence the default script is retry, and a second side effect on a non-idempotent path happens after “failure.”

Where it stops holding

When security cannot describe the side effect, it can still be classed none / present / unknown, with matching actions (retry / inspect / get help). Some side effects appear seconds later (an async queue); marking unknown now is more honest than pretending “none,” with a time at which it becomes known. Successful items have side effects by default and need not declare each one; declaration is for failed and unknown items.

Applying it

• For each failure class, keep a side-effect grade: definitely did not happen, definitely did, unknown. The grade chooses the button: retry, inspect, or both with inspect as default.
• Copy on unknown items must not be only “failed, please retry”; “this may already have completed” has to appear.
• Reconciliation carries that item’s idempotency key or business identifier, so people are not guessing by eye in a list.
• Verify on an item that actually charged but the client saw failure. If the first move is pay again rather than inspect, the side effect was not named.

Related

• Within the group: H3.13.1 Partial batch failure needs per-item status · H3.13.2 Failed items need their own retry, not a full redo · H3.13.3 Partial success must not be labeled as total failure
• Adjacent: H3.10 Retry strategy · H7.13 Payment failure and unknown state · H3.02 Three elements of error messages
• Search terms: side effect · timeout is not failure · partial failure