Review error handling

Error-handling defects stay invisible until production: an empty catch turns an outage into silent data loss, a retry loop around a non-idempotent call charges a customer twice, a missing timeout lets one slow dependency exhaust every worker, and a raw exception message shows a SQL query to an end user. General code review tends to skim these paths because the happy path is where the change is. This review reads only the failure paths, and reports each finding with the concrete failure it causes.

Review the error handling in: [CODE] Only if [LANGUAGE] is given: Language and framework: [LANGUAGE]

For every call that can fail (I/O, network, database, parsing, external services, user input), follow what happens on failure and check:

1. Swallowed errors: empty catch or except blocks, ignored return values or error results, promises without a rejection handler, catch that logs and continues where the caller needs to know, fallbacks that hide failure (returning an empty list on error).
2. Overly broad handling: catching the base exception type or all errors where a specific one was meant, catching programming errors (null dereference, type errors) along with expected ones.
3. Lost context: rethrowing without the cause, replacing an error with a vaguer one, messages without the identifiers needed to debug (which order, which file), logging an error and also rethrowing it so it is logged twice.
4. Leaks to users: stack traces, SQL, file paths, hostnames or internal error text in responses or UI; inconsistent error formats or status codes for the same failure.
5. Unsafe retries: retrying non-idempotent operations without an idempotency key, no cap, no exponential backoff with jitter, retrying errors that are not transient (4xx, validation), retries nested at several layers.
6. Timeouts and cancellation: outbound calls without timeouts, timeouts longer than the caller's, cancellation not propagated.
7. Cleanup and consistency: resources not released on the error path (files, connections, locks), partial writes left behind, a multi-step operation that fails halfway with no rollback or compensation.
8. Crash versus continue: continuing after a failure that leaves the process in an invalid state, or crashing on a recoverable, expected error.

Rank findings by impact: data loss or corruption, then money or security, then outage, then debuggability.

• Each finding needs a location and a concrete failure scenario. If you cannot describe the input or condition that triggers it, drop it.
• Report at most 12 findings. Do not comment on style, naming or the happy path.
• Fixes must follow the language's idioms (wrapping with a cause, errors.Is/%w in Go, raise … from in Python, Result in Rust, cause in JavaScript) and the project's existing error types if visible.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.

Summary

One or two sentences: overall state and the most serious risk.

Findings

Numbered, most severe first. Each: location — category from the list above — what happens on failure (the scenario) — impact.

Fixes

For the top findings, a short code snippet of the corrected handling.

What is done well

Bullets, or "Nothing notable".