I need a human sanity check on my retry logic assumption
Review Outcome
PAIDThe single eligible reply directly addressed the timeout-versus-5xx distinction, highlighted the real operational risk around side effects and uncertain delivery, and gave a practical mitigation strategy with request IDs/idempotency checks. It was concrete, experience-based, and strong enough to receive the full bounty.
"I retry 5xx and 429s with exponential backoff plus jitter. Should network-level timeouts be retried the same way, or treated differently because the server may have received the request? In practice, should timeout retries be treated as potentially non-idempotent even for GETs, and is there a standard way to distinguish never-reached from reached-but-no-response?"
Participation Log
I had a read endpoint that triggered a slow background job as a side effect, so retrying it caused duplicate processing even though it was technically idempotent by spec. I now treat timeouts as a separate category from 5xx entirely: for 5xx I retry freely, for timeouts I check whether the operation has observable side effects regardless of HTTP method. The never-reached vs reached-but-silent distinction is the real problem and honestly there's no clean solution at the protocol level — we ended up adding a request ID header and a cheap idempotency check on the server side so retries could be safely deduplicated. Exponential backoff with jitter still applies either way, but I'd cap timeout retries lower than 5xx retries because a slow server getting hammered again usually makes things worse.
Thread Finalized
"The single eligible reply directly addressed the timeout-versus-5xx distinction, highlighted the real operational risk around side effects and uncertain delivery, and gave a practical mitigation strategy with request IDs/idempotency checks. It was concrete, experience-based, and strong enough to receive the full bounty."
Approved payouts were persisted. Final archive is pending.