aissia/docs/03-implementation/configuration/error-handling.md

# Error Handling & Reliability System

**Points 291-310 - Error Handling** - Anti-cheat validation, input responses, module failures, network issues

## Engine Crash/Restart Strategy

### Detection System
**Health monitoring automatique** :

```bash
# Health check HTTP
GET /health toutes les 30 secondes

# Redis heartbeat
PUBLISH engine:heartbeat {"engine": "factory", "timestamp": "..."}

# Timeout detection
Si pas de heartbeat depuis 60s = engine down
```

### Recovery Automatique
**Restart et state restoration** :

```cpp
// Engine redémarre → republish état current dans Redis
// Example: Factory Engine restart
PUBLISH factory:status {"active_productions": [...]}

// Autres engines reçoivent l'update et ajustent leur état local
```

### Graceful Degradation
**Fallback vers cache local** :

```cpp
// Dans chaque engine
if (!canReachEngine("economy")) {
    // Utiliser derniers prix connus en cache
    price = fallbackPriceCache.get(resource);
    logWarning("Using cached price, Economy engine unreachable");
}
```

## Redis Failover Strategy

### Persistence Configuration
**Redis durability** :

```bash
# Configuration Redis
save 900 1     # Save snapshot if 1+ keys changed in 15min
appendonly yes # Log toutes les commandes
```

### Multiple Instances
**High availability setup** :

```bash
Primary Redis: 6379 (read/write)
Replica Redis: 6380 (read-only backup)
Si primary down → engines switch automatiquement vers replica
```

### Message Replay
**State recovery après Redis restart** avec replay des messages critiques.

## Anti-cheat & Validation

### Server Authoritative Design
- **Toute logique métier** côté serveur
- **Anti-cheat naturel** via validation centralisée
- **Zero game logic** côté client

### Anti-cheat Psychologique
**Stratégie : Cheat attempts → "bugs" simulés progressifs**

```cpp
class AntiCheatPsycho {
    void onCheatDetected(CheatType type) {
        switch(type) {
            case SPEED_HACK:
                simulateRandomLag(50ms, 500ms);
                break;
            case RESOURCE_HACK:
                simulateVisualGlitches(tanks, 5%);
                break;
            case DAMAGE_HACK:
                simulateDesync(movement, 2%);
                break;
        }
    }
};
```

### Input Validation
- **V1 Thin Client** : Validation authoritative serveur
- **V2 Client Prediction** : Validation + réconciliation
- **Build verification** : Hot-reload seulement si build réussi

## Network Issues & Module Failures

### Module Isolation
- **Failures localisées** : Pas de cascade entre modules
- **Module autonomy** : Continue avec dernières données reçues
- **Async communication** : Redis Pub/Sub pour resilience

### Timeout Handling
- **Fallback patterns** : Cache local si engine unreachable
- **Graceful degradation** : Fonctionnalité réduite vs crash total
- **State preservation** : Maintien état durant failures temporaires

## Sources

**Documentation originale :**
- `docs/global/architecture-technique.md` - Section "Error Handling & Reliability"
- `docs/toCheck/architecture-modulaire.md` - Anti-cheat psychologique
- `docs/architecture-technique.md` - Validation patterns

**Points couverts :** 20 spécifications error handling détaillées