Skip to main content

Errors, Timeouts and Retries

What this concept is​

A network request can fail before an HTTP response exists, or receive an HTTP response reporting a problem. A timeout bounds some waiting; a retry repeats an operation and must account for whether the earlier attempt may have had effects.

Why it matters here​

If every failure becomes an empty list, your report cannot distinguish “no sessions” from “the service is unavailable.” If every failure triggers unlimited retries, a small script can hang or worsen load.

Concrete example​

A response from /unavailable has status 503. The adapter preserves the status and body, and the interpreter rejects it. If no service is listening, connection establishment can fail without any HTTP status. The supplied adapter lets that transport error propagate.

Its two-second timeout applies to blocking operations in the underlying library, not a guaranteed total deadline for an entire distributed workflow. The fixture does not implement retries. In a later production client you would classify retryable errors, cap attempts and elapsed time, and consider operation semantics.

Common confusion / misconception​

An exception is not proof that the server did nothing. A response may be lost after a state change. Even a read-only request should not be retried forever. A local passing test does not establish Internet reliability, DNS behavior or TLS correctness.

How to use it​

Record whether you observed a status, a parsing failure or a transport exception. Set explicit resource limits. Keep retries out until you can state when repetition is acceptable and when to stop. For the learning lab, show a clear failure and preserve the original input/evidence rather than hiding it behind fallback data.

Check yourself​

Should a timed-out payment request be repeated just because no answer arrived? Not without understanding whether the first attempt took effect and how duplicates are controlled. That production problem is deferred; the principle still explains why automatic repetition needs a contract.

Mini drill or application​

Draw the path from connection to response validation. Place connection refusal, 503, wrong content type and invalid JSON at their respective stages. Explain what your current local tests do and do not exercise.

Read this only if stuck​

Python urllib.request documents timeout and response behavior. Consult error types when a real trace is confusing; do not catch everything merely to print success.