Retour à l’état précédent en cas d’erreur et résolution des conflits

Annuler un ajout optimiste (retirer l’élément) ou une suppression (restaurer l’élément) est simple. Annuler une mise à jour est plus complexe : vous devez restaurer exactement la valeur précédente. Si l’élément a été mis à jour plusieurs fois de manière optimiste, vous devez suivre chaque valeur précédente séparément, et non pas seulement l’état initial du serveur.

Prenons le scénario suivant : le serveur contient un élément dont la valeur est Z. Vous le mettez à jour de manière optimiste pour lui attribuer la valeur X. Pendant que votre requête est en cours, un autre utilisateur met à jour le même élément et lui attribue la valeur Y sur le serveur. Votre requête arrive et le serveur la rejette (conflit). La cible de votre annulation est Z, mais l’état actuel du serveur est Y. Restaurer Z écraserait donc Y à tort.

La stratégie d’annulation la plus sûre pour les mises à jour consiste à recharger l’élément depuis le serveur après toute erreur de mutation, plutôt qu’à restaurer un instantané capturé localement. Ainsi, vous affichez toujours l’état de référence du serveur, quelles que soient les modifications concurrentes effectuées par d’autres utilisateurs. Le rechargement est plus lent, mais toujours correct.

Une API bien conçue renvoie HTTP 409 Conflit lorsqu’une mise à jour optimiste échoue en raison d’une modification concurrente. Le corps de la réponse inclut généralement l’état actuel du serveur. Votre gestionnaire d’erreurs doit détecter 409, utiliser le corps de la réponse pour mettre à jour votre état local avec la valeur actuelle du serveur et informer l’utilisateur que ses modifications n’ont pas été enregistrées.

Une mutation idempotente produit le même résultat lorsqu’elle est appliquée plusieurs fois. Concevoir des mutations idempotentes (en utilisant PUT au lieu de POST, en incluant l’état complet de la ressource et en utilisant des clés d’idempotence) permet de réessayer sans risque en cas d’échec, sans appliquer la modification deux fois. Cela simplifie considérablement la logique d’annulation.

Les double-clics sur un bouton d’envoi peuvent déclencher deux mutations identiques. Évitez cela avec un indicateur isSubmitting : définissez-le sur vrai au démarrage de la mutation, puis remettez-le à faux lorsqu’elle se termine (qu’elle réussisse ou échoue). Désactivez l’élément déclencheur lorsque isSubmitting vaut vrai. Cela élimine les mutations en double au niveau de l’interface utilisateur.

Pour la déduplication côté serveur, incluez un en-tête Idempotency-Key unique dans chaque requête de mutation. Générez-le avec crypto.randomUUID() lorsque l’utilisateur déclenche l’action. Le serveur détecte les clés en double et renvoie la même réponse que pour la requête initiale sans réappliquer l’opération.

Pendant qu’une mutation est en cours, vous pouvez afficher un indicateur discret signalant que l’état optimiste n’est pas confirmé : un petit point clignotant, le texte « Enregistrement… » ou une opacité réduite sur l’élément. Cela communique l’incertitude sans bloquer l’interaction. Supprimez l’indicateur en cas de réussite ou annulez la mise à jour en cas d’échec.

Les erreurs inattendues dans la logique d’annulation (par exemple, l’accès aux propriétés d’une valeur indéfinie pendant la restauration de l’état) peuvent faire planter le composant. Encapsulez les composants qui utilisent intensivement les mutations dans une frontière d’erreur afin que les échecs catastrophiques de l’annulation affichent une interface d’erreur élégante plutôt qu’un écran vide. Consignez ces erreurs pour faciliter le débogage.

Une stratégie fiable de détection des conflits consiste à inclure un numéro de version ou un ETag dans chaque mutation. Le serveur compare la version envoyée par le client à sa version actuelle. Si elles diffèrent (une autre mise à jour a eu lieu), il renvoie 409. Il s’agit du contrôle de concurrence optimiste : vous supposez l’absence de conflit, mais vous le détectez lorsqu’il survient.

La logique d’annulation est souvent laissée sans tests, car les défaillances réseau sont difficiles à simuler. Utilisez des outils tels que Mock Service Worker (MSW) pour renvoyer des réponses d’erreur dans les tests. Écrivez des tests explicites pour : la gestion du conflit 409, l’annulation après dépassement du délai d’attente réseau, la déduplication des double-clics et la cohérence de l’état après un échec. C’est dans ces cas limites que se cachent les bogues.

Quel code d’état HTTP une API bien conçue renvoie-t-elle lorsqu’une mise à jour optimiste échoue en raison d’une modification concurrente effectuée par un autre utilisateur ?

L’annulation d’une mise à jour est plus complexe que celle d’un ajout ou d’une suppression : rechargez toujours les données en cas d’erreur pour éviter les problèmes liés aux instantanés obsolètes. Le conflit HTTP 409 signale les échecs de concurrence optimiste ; utilisez le corps de la réponse pour restaurer l’état actuel du serveur. Concevez des mutations idempotentes pour permettre des nouvelles tentatives sûres. Empêchez les déclenchements en double avec isSubmitting et des clés d’idempotence côté serveur. Testez explicitement les chemins d’annulation en utilisant MSW pour simuler les erreurs.