Code Review: FRE-328 - Error Handling

Verdict: APPROVED with suggestions

Reviewed all 3 files in src/errors/:

__init__.py (33 lines)
pipeline_errors.py (269 lines)
error_recovery.py (376 lines)

Strengths

✅ Well-designed exception hierarchy with context and recovery hints ✅ Comprehensive retry strategy with exponential backoff and jitter ✅ Graceful degradation for non-critical failures ✅ Central ErrorRecoveryManager for coordination ✅ Good use of TypeVar for generic decorators

Suggestions (non-blocking)

1. pipeline_errors.py:134 - Operator precedence bug

if not default_hint and "OOM" in message or "GPU" in message:

This evaluates as if (not default_hint and "OOM" in message) or ("GPU" in message) due to operator precedence. Should be:

if not default_hint and ("OOM" in message or "GPU" in message):

2. error_recovery.py:56 - Import inside method

def calculate_delay(self, attempt: int) -> float:
    import random  # Should be at module level

3. error_recovery.py:138 - Off-by-one in retry loop

for attempt in range(max_retries + 1):  # Runs max_retries + 1 times

The should_retry method uses 0-indexed attempts, which may cause confusion. Consider aligning with the max_retries count.

4. error_recovery.py:187-197 - Potential logic issue

if is_critical and not self.strict_mode:
    self.warnings.append(...)  # Adds warning but still skips!
return True  # Always returns True regardless of is_critical

When is_critical=True and strict_mode=False, a warning is added but the segment is still skipped. This may not be the intended behavior.

Overall Assessment

Solid error handling implementation with comprehensive recovery strategies. The issues identified are minor.

1.8 KiB Raw Blame History