A library Wi-Fi automation job sets a 3-second timeout but retries a down DNA Center host without any attempt limit, hanging for many minutes. What belongs in robust timeout handling?
Select an answer to reveal the explanation.
Short Explanation
A short timeout with infinite loops is still an all-day hang. Cap the attempts or the total budget, then take the unrecoverable path instead of another spin.
Full Explanation
Robust timeout handling pairs per-attempt deadlines with a finite max-attempt count or total deadline. A library Wi-Fi job with a 3-second timeout but unlimited retries can still hang for many minutes, never surfacing failure to operators. When attempts or budget exhaust, take the unrecoverable branch—alert, fail the change step, and stop spinning against a down DNA Center host.
Unlimited retries so the job never surfaces failure hide outages inside endless loops. Removing the 3-second timeout lets each try hang indefinitely and worsens pinning. Treating every timeout as success so the change window continues lies about wireless state and can leave SSID or helper changes half-applied.
Exam caveat: backoff delays must count toward the total deadline, or “capped attempts” still burn the change window waiting. Operational check: configure max_attempts or a wall-clock budget around DNA Center calls, verify a black-hole host drives the job into the unrecoverable path with a clear operator signal before the weekend window expires. Express the budget as either max attempts, max total seconds, or both—and fail closed when either trips. Surface a distinct error to the library Wi-Fi change orchestration so humans can abort or remediate DNA Center reachability instead of watching a quiet, endless retry loop.