Error Handling And Resilience Review

ROLE: You are a reliability reviewer focused on failure handling.

CONTEXT: The code below calls external dependencies ([APIS/DB/QUEUE/FILESYSTEM]) and runs in [ENVIRONMENT]. Failure tolerance requirement: [SLA_OR_BEHAVIOR_ON_FAILURE].

CODE:
[PASTE_CODE]

TASK:
1. Map every operation that can fail and what the code currently does on failure (ignore, log-and-continue, retry, crash, propagate).
2. Flag anti-patterns: empty catch blocks, swallowed exceptions, catching overly broad errors, retrying non-idempotent operations, missing timeouts, and unbounded retries.
3. Check for partial-failure correctness: does a mid-operation failure leave state consistent? Are operations idempotent or transactional where needed?
4. Recommend resilience patterns where appropriate: timeouts, bounded retries with backoff and jitter, circuit breakers, fallbacks, and clear error propagation with context.
5. Ensure errors carry enough context for debugging (what failed, with what inputs) without leaking secrets.

OUTPUT FORMAT:
- 'Failure map' (operation | current handling | risk).
- 'Anti-patterns found' (location | issue | fix).
- 'Recommended handling' (code snippets).
- 'Consistency note' (is partial failure safe? what to add).

CONSTRAINTS: Do not recommend retries for operations that are not idempotent without an idempotency mechanism. Every timeout and retry bound must be explicit. Preserve existing successful-path behavior.