The decision
A timeout tells you that a caller stopped waiting, not necessarily that a provider stopped working. Decide how long the browser should wait, how long the server may work, and what happens if a result arrives late. Use bounded retries only for failures that are safe to repeat.
A worked example
A note-to-draft job receives a stable request key. The server stores a pending job before calling the provider. If the browser loses connection, it can request the same job’s state rather than creating a second generation. The worker records completion or a failure that leaves the note available for another attempt.
How to put it into practice
- Set explicit timeouts at each layer and leave time for cleanup and persistence.
- Use capped exponential backoff for transient failures, with a maximum attempt count.
- Store job status and request identity before starting expensive work when refresh or retry must recover it.
- Define cancellation and late-result behavior rather than relying on a spinner indefinitely.
A failure to plan for
Unlimited retries can turn an outage into a cost spike. A retry budget should include both request count and spend. Do not retry invalid input or missing authorization as if they were temporary network errors.
Try it on your project
Simulate a provider that responds after the caller times out. Refresh the page and submit again. Confirm that you can explain whether one or two model calls occurred and where the result is stored.
Keep the next step small
Use the free demand scorecard or planning tools to make your assumptions explicit. The $19 launch kit brings the blueprint and seven editable worksheets together.