38. Clients HTTP serveur : délais, tailles et reprises

Comprendre le mécanisme

Un client HTTP serveur possède plusieurs étapes : résolution, connexion, négociation, attente et lecture du corps. Une option nommée timeout peut viser une période d’inactivité plutôt qu’une durée totale ; lisez le contrat exact de la bibliothèque. Une réponse qui arrive lentement par petits morceaux peut donc consommer plus de temps que prévu si seul un délai partiel est configuré. Le volume du corps doit également être borné.

Raisonner et vérifier

Fixez un budget de bout en bout compatible avec celui de l’appelant. Les reprises ajoutent du travail et peuvent aggraver une saturation, surtout lorsqu’un effet distant est incertain. Réservez-les aux cas compatibles avec le contrat d’idempotence, bornez leur nombre et leur durée, et appliquez une attente adaptée. Vérifiez aussi l’annulation et le traitement des erreurs : une tâche client abandonnée ne prouve pas que le service distant a cessé son effet.

Contrat du timeout

Un timeout peut viser l’inactivité plutôt que toute la durée. La sémantique dépend de la bibliothèque. Une option peut mesurer inactivité ou une étape de connexion plutôt que durée totale. Consultez le client employé et testez le comportement ; le nom timeout ne garantit pas un budget global uniforme.

Volume

Le volume de réponse doit être borné. Temps et taille sont des limites indépendantes. Limitez les octets lus et, si pertinent, décompressés. Une réponse rapide mais énorme peut épuiser la mémoire disponible ou l’espace disque malgré une échéance temporelle correctement configurée.

Retries

Les retries consomment un budget supplémentaire. Il crée un travail et un trafic supplémentaires. Chaque tentative ajoute du travail au service distant et consomme votre budget. Une dépendance saturée peut devenir encore moins disponible si tous ses clients reprennent immédiatement sans limite ni attente.

Mutation reprise

La reprise d’une mutation demande un contrat d’idempotence. L’effet distant peut avoir réussi avant la perte de réponse. Un timeout ne prouve pas l’absence d’effet. Pour une création ou un paiement, conservez une identité stable et utilisez le mécanisme d’idempotence ou de réconciliation du fournisseur avant toute nouvelle intention.

Flux lent

Une lecture lente peut rester active par petits morceaux. Il faut distinguer inactivité et durée de bout en bout. Un serveur peut envoyer quelques octets régulièrement et éviter un timeout d’inactivité. Une durée totale maximale reste nécessaire pour borner l’occupation du worker dans ce scénario.

Annulation

L’annulation locale ne prouve pas l’arrêt distant. Les effets peuvent continuer côté service. Arrêter l’attente locale ne démontre pas que le traitement distant s’est arrêté. Conservez un état incertain et recherchez le résultat si l’opération peut avoir produit un effet durable.

Budget de l’appelant

Un budget doit être compatible avec celui de l’appelant. Les durées s’additionnent et consomment des ressources. Le temps accordé à une dépendance doit laisser place au traitement et à la réponse du service appelant. Empiler des délais plus longs que la requête entrante peut créer un travail devenu inutile.

Tentatives bornées

Le nombre de tentatives doit être borné. La reprise peut amplifier la panne. Fixez nombre maximal, délais et budget global, avec jitter lorsque pertinent. Une règle d’arrêt doit rester applicable même si chaque tentative individuelle semble terminer dans son propre délai.

Erreurs de phases

Les erreurs simulées doivent couvrir connexion et lecture. Les phases possèdent des échecs différents. Testez connexion impossible, lecture interrompue et flux lent avec services factices. Un seul refus immédiat ne vérifie pas les budgets et états incertains des autres phases.

Diagnostics minimisés

Le diagnostic doit minimiser les secrets des appels. La surveillance ne doit pas exposer les capacités utilisées. Conservez fournisseur, phase, durée et catégorie d’échec sans URL contenant un secret ni header d’authentification. Un message d’exception de client doit être revu avant d’être exposé ou journalisé tel quel.

Atelier guidé : lire, expliquer et vérifier le code

# Options d’un appel HttpClient :
timeout: 1.0
max_duration: 3.0

Dans ce contrat HttpClient, timeout et max_duration couvrent deux dimensions temporelles. Le premier peut viser l’inactivité, le second une durée totale maximale. Testez un flux qui envoie régulièrement de petits morceaux pour démontrer pourquoi ces deux limites ne sont pas interchangeables.

L’idempotence demande un contrat séparé. Une durée n’est pas une limite de volume. Le budget ne vérifie pas l’identité TLS. Les options répondent à deux dimensions temporelles différentes.

Travail pratique : Simulez une dépendance silencieuse, une dépendance envoyant lentement et une réponse trop volumineuse.

Critères de correction : Mesurez le temps total et la mémoire, puis vérifiez le refus borné et l’absence de reprise incontrôlée. Ajoutez un cas où la réponse d’une mutation est perdue ; démontrez la politique d’idempotence avant d’activer un retry.