RELIABILITY AND ERROR RECOVERY

HANDLING TOOL TIMEOUTS AND STALE DATA You learned about timeouts in Chapter 55. Here we focus on what to do after one. First, treat a timeout as information, not as a mystery. Record it, then decide among retrying, using a fallback, or reporting failure. Second, beware of the uncertain outcome. If a call to "send the email" times out, you do not know whether the email was sent. Retrying could send it twice. This is why idempotency keys and status checks matter. Third, watch for stale data. Stale data is information that was accurate when collected but has aged. An agent that quotes yesterday's price or last week's inventory as if it were current may mislead a user. Defenses include attaching timestamps to data, setting expiry times, re-fetching data before important decisions, and telling the user how fresh the information is.