The Bot That Never Fails (and Never Finishes)
A data-extraction bot processes a web portal and writes results to a spreadsheet. It has been 'successful' for months, but the business notices the spreadsheet stopped growing two weeks ago. Investigation shows the portal added a new cookie-consent banner; the bot's element selector for the 'next page' button now matches the banner's close button instead. The bot clicks it, the page does not advance, and the loop runs until a 60-minute timeout, after which the job is marked 'completed' because the top-level error handler swallows all exceptions and logs them at debug level. No alerts fired. The bot owner left the company.
1. Explain how a bot can report success while producing no output, and what design and monitoring failures this exposes.
Read the worked answer
How it 'succeeds' with no output: The selector for the next-page button became ambiguous after the portal added a consent banner. The bot clicked a matching-but-wrong element, so the page never advanced. The loop kept iterating until the 60-minute timeout. The top-level handler caught every exception and logged at debug level, so the job's terminal state was 'completed' with no surfaced error. Result: a green dashboard and zero data - a silent failure.
Design failures:
- Fragile selectors: A selector that can match an unrelated element (the banner) instead of the intended button; no uniqueness or fallback strategy.
- No output validation: The bot never checked that the page actually advanced or that rows were extracted. A simple 'did the page change / did row count increase' check would have caught it on the first iteration.
- Catch-all error handling: Swallowing all exceptions at the top level defeats error handling; the job should fail loudly on unexpected conditions.
- No loop guard: No max-iterations or no-progress detection; it spun for an hour.
Monitoring failures: No alerting on output volume, no freshness check on the spreadsheet, and no owner (the owner left) meant nobody noticed for two weeks.
2. Propose concrete changes to make this class of silent failure impossible or immediately visible.
Read the worked answer
Attack it at three layers:
1. Robust interaction:
- Use unique, resilient selectors (attributes/anchors, not generic buttons); add fallback selectors and validate the matched element before clicking.
- Detect and dismiss the consent banner explicitly at start if present.
2. Progress and output validation:
- After each page action, assert the page advanced (URL/page-number change, or expected content present). If not, raise a clear exception.
- Guard the loop with a max-iteration count and a no-progress detector (e.g., same page state twice → fail).
- Validate output: assert rows extracted > 0 and that the spreadsheet grew; treat zero-growth as a failure.
3. Error handling and monitoring:
- Remove the catch-all that logs at debug. Unexpected exceptions should mark the job failed, with a clear message, and route to an alert/exception queue.
- Add freshness/volume monitoring on the spreadsheet (e.g., alert if no new rows in 24h) independent of the bot's own status.
- Assign an owner and a documented runbook; require ownership handoff when staff leave.
Principle: A job's success should mean 'produced correct output,' not 'did not throw.' Validate outcomes, not just execution.