03 : les erreurs réseau deviennent des erreurs retentables

[arsenik-dtheo]

Partie de l'épic #6. Bloqué par #1.

🧮 Position dans la pile	03
🌿 Branche attendue	epic-6/03-erreurs-connexion
📦 Profil	tracer bullet

🎯 À construire

Les échecs au niveau réseau — connexion refusée, échec DNS, timeout de connexion/lecture/écriture, connexion réinitialisée, flux coupé — cessent d'être levés bruts : ils sont encapsulés dans une nouvelle Typesafe::ConnectionError, sous-classe de APIError marquée retentable. Une coupure brève est donc absorbée par la boucle de retentative du ticket 01 ; à épuisement, la ConnectionError est levée avec l'exception d'origine conservée en cause. L'appelant garde un unique rescue Typesafe::Error pour tous les échecs.

✅ Critères d'acceptation

• Un échec réseau (ex. connexion refusée) est retenté selon la politique par défaut, puis — en cas de succès — l'appel renvoie la réponse normalement
• À épuisement des retentatives sur échec réseau, une Typesafe::ConnectionError est levée, sous-classe de APIError, avec l'exception d'origine en cause
• Aucune exception réseau brute (Net::HTTP, SocketError, timeouts) ne s'échappe plus de Client#evaluate
• La ConnectionError est traitée comme retentable : elle suit exactement la même politique de délai que 429/529/5xx

🔗 Bloqué par

• #1 — la boucle de retentative doit exister pour rejouer un échec réseau

🚧 Ce que ce ticket ne fait pas

• La liste exhaustive des exceptions enveloppées est un choix d'implémentation, à arrêter en codant (délibérément non tranché en affinage)

📚 Références

• Épic : retry-client: retentatives automatiques dans le client HTTP #6
• Spec : docs/plans/retry-client/spec.md — ## Décisions d'implémentation, ## Décisions de test
• Glossaire : LEXIQUE.md · ADR : docs/adr/0001-retentatives-automatiques-par-defaut.md