The Import Job That Always Succeeds
Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.
A nightly patient-record import reports success every night. Downstream teams have been working from data that turned out to be missing three weeks of records. Each record is processed inside try { ... } catch (e) { logger.debug(e) }.
Changing logger.debug to logger.error and rethrowing. The errors are now loud, the alerting fires, and the review approves it as obviously correct — "never swallow exceptions" is a rule everybody agrees with. The next night one malformed row from an upstream system stops the other forty thousand from importing, which is precisely the failure the original catch existed to prevent. You have traded a silent-partial-success for a noisy-total-failure, and made the change under the impression that you removed a defect rather than swapped one. The two failures have different owners and different costs, and choosing between them is the actual design decision.
Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.