nightnight

CODE_REVIEW_FRE-328.md

@@ -0,0 +1,49 @@
+# 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
+```python
+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:
+```python
+if not default_hint and ("OOM" in message or "GPU" in message):
+```
+
+### 2. error_recovery.py:56 - Import inside method
+```python
+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
+```python
+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
+```python
+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.