timeouts Shipped
What this lens looks for
Every request must set both a connection timeout (TCP + TLS handshake; default ~10 seconds) and a read/response timeout (time to first byte; default ~30 seconds), and where applicable a total/request timeout covering the entire lifecycle including retries (default ~60-120 seconds); infinite timeouts must never be used, so flag any request configured with no timeout or with a 0/null/disabled timeout that lets it block forever. For long-running operations, the answer is not to stretch these timeouts — use the 202 Accepted plus polling pattern instead of extending or removing timeouts to accommodate slow work.
What its verifier checks
Both a connection timeout and a read/response timeout are configured on every request (neither omitted), with the connection timeout around 10s and the read timeout around 30s; a total/request timeout bounding the full lifecycle including retries is present where applicable (~60-120s); no request uses an infinite, 0, null, or disabled timeout; long-running operations return 202 Accepted with a polling endpoint rather than extending or removing timeouts to wait out the work.