Intermittent Save Timeout at 02:00
An unattended bot processes 250 claim transactions nightly between 01:00 and 04:00. In the last 30 days it failed 3-6% of transactions at the same point: after opening a claim modal, clicking Save sometimes times out after 30 seconds. A retry of the whole transaction succeeds about 70% of the time. Logs show the Save selector uses a dynamic index and the application server is busiest at 02:00. The bot currently catches System.Exception at the top level, logs the message, and marks the queue item Failed. Operations rerun failed items manually each morning.
1. What is the most likely exception category and root cause, and what evidence would you collect before changing the retry or timeout?
Read the worked answer
It is a system or UI exception, not a business rule exception: the Save action times out. The dynamic index in the selector is suspicious, but the timing, with the server busy at 02:00, and the 30-second timeout also point to application latency or a modal that is slow to become interactive. Before changing anything, collect the full selector and UI tree at failure, a screenshot before and after the click, whether the click event fired, the application's response time, and whether the claim actually saved despite the timeout. Check whether failures cluster on one robot, one machine template, or one claim type. Compare successful and failed transactions. Increasing the timeout without this check may hide a duplicate-submission risk.
2. Redesign the exception handling. Address whole-transaction retry versus action-level retry, queue status, idempotency, and alerting.
Read the worked answer
Put a Retry Scope around the Save action, not blindly around the whole transaction. First verify whether the modal is present, then click Save, then wait for a confirmation element. On timeout, check idempotency: search for the claim ID or saved status before retrying. If it saved, mark success and log the late confirmation. If not, retry the click up to two times with a short interval. If it still fails, take a screenshot and UI tree, attach them to the queue item, and set the item to Retry if the retry count is below the limit; otherwise Failed with a system-exception reason. Use BusinessRuleException only for validation failures.
Remove the broad top-level catch that flattens everything to Failed. Alert operations when the hourly failure rate exceeds 2% or when the same selector fails three times in a row.