You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
Should a failed operation be retried or handled differently?
Missing, unsupported, denied and conflicting operations need different responses.
If an agent interprets every failed report read as “try again,” it may repeat an operation that cannot succeed. An interface showing only “something went wrong” leaves the person with the same problem.
Distinguish the meaning of the failure first:
| Situation | Meaning | A reasonable next step |
|---|---|---|
| Missing resource | This environment cannot find the target at that address | Check the address and whether the resource moved |
| Unsupported operation | The implementation does not provide the operation | Inspect capabilities and choose a supported route |
| Denied access or read-only | The request violates access restrictions | Check authority or request an appropriate action from an authorized participant |
| Version conflict | The edit was based on stale content | Read the current version and resolve the difference |
AFS uses different error codes for these categories. Programs can handle the category rather than matching human-readable wording.
Retries still help with some temporary failures, such as a network interruption. But consider whether an action already took effect. Missing a voting response does not prove that the vote was not recorded. The application needs the action’s retry agreement and a way to establish state, rather than unconditionally submitting again.
Stable operation semantics include failure: consumers should understand what did not happen, what remains uncertain and what they can do next.
Go deeper
Check your understanding
Does a missing voting response prove failure and justify an immediate repeated submission?
No. The action may have executed. Establish its state under the retry contract to avoid repeated effects.
Continue along a learning path
- Take resources across boundariesStep 5 of 5