An enterprise SERP client needs a failure budget that the application can explain. Define when a request times out, which errors can be retried, when a circuit stops new work and whether a stale result is allowed. More retries do not automatically improve reliability.
Describe the state transitions
| State | Allowed action | Recorded result |
|---|---|---|
| Ready | Send within caller deadline and capacity | Request identity and attempt |
| Transient failure | Retry only while eligible and within budget | HTTP/API error and delay |
| Budget exhausted | Stop | Explicit unavailable result |
| Circuit open | Reject or use a permitted fallback | Circuit reason and fallback label |
| Recovery probe | Run a controlled test request | Probe outcome before reopening |
Keep business errors distinct from transport failures
Validate the HTTP result before interpreting a JSON business status. Authentication, malformed configuration and a valid empty SERP are different cases. Retry only documented or application-approved transient failures, respect Retry-After where supplied and keep the delay inside the caller deadline.
An optional last-known-good result needs its source time and stale label. For a task that requires current evidence, the permitted result may simply be unavailable. Do not hide a stale answer behind a successful HTTP response.
Verify the boundary with a local server
The Go httptest cases exercise these local behaviors. They do not establish a vendor SLA or a measured production uptime figure.
- Return a transient error followed by success and assert the finite attempt count.
- Return an authentication error and confirm it is not blindly retried.
- Cancel while waiting for capacity and verify that the call stops.
- Exhaust the budget and preserve the failure category.
Reference documentation: www.searchcans.com — /google-search-api; pkg.go.dev — /net/http.
