Bibliothèque de lecture
Distinguez à l'écran résultats vides et échecs de transport
Séparez une recherche de quantification réussie mais vide des erreurs HTTP et de l'absence de réponse, en conservant la question envoyée et un renvoi volontaire.
Distinguez les catégories de réponse
Une zone de résultats vide n'explique pas le sort d'une recherche. Dans le carnet LocalLLaMA proposé, distinguez une requête encore en cours, une réponse réussie contenant des enregistrements, une réponse réussie avec un tableau data vide, une erreur HTTP et une tentative de transport sans réponse exploitable. Ce sont des observations différentes. En particulier, un succès vide ne prouve pas que l'archive ne contient aucune discussion pertinente ; une réponse perdue ne révèle pas si le serveur a terminé la requête. Ne fondez pas ces interprétations dans le raccourci visuel « aucun résultat ».
Utilisez ensemble le statut HTTP et la structure validée de la réponse. Une réponse 200 contenant data: [] correspond à une récupération réussie mais vide. Les statuts HTTP 400, 401, 402, 429 et 502 sont des réponses d'erreur, pas d'autres formes de succès vide. Une exception réseau peut ne fournir aucun statut HTTP. Ne déduisez pas d'une erreur seule que la requête a atteint toutes les étapes du backend. Conservez avec chaque résultat les paramètres envoyés et un identifiant de requête propre à l'application, afin de rattacher une réponse tardive à la bonne recherche.
Proposez des actions adaptées au résultat vide
Préférez un texte mesuré : « Aucun enregistrement n'a été renvoyé pour cette requête. » Affichez à proximité q=quantization et subreddit=LocalLLaMA tels qu'envoyés, ainsi que les éventuelles restrictions de date ou de score. Permettez de modifier volontairement une condition puis de renvoyer la requête. Ne remplacez pas la réponse vide par des discussions populaires inventées et n'élargissez pas automatiquement la recherche en conservant l'ancien libellé. Si le lecteur retire un filtre, le prochain résultat appartient à cette requête modifiée et doit commencer une nouvelle séquence à la page 1.
Expliquez une contrainte pertinente sans prétendre diagnostiquer l'absence. Pour quantization memory, tous les termes analysés doivent correspondre dans un même champ title ou text ; leur répartition entre les deux ne suffit pas. C'est un élément possible à examiner, pas la preuve de la cause de cette réponse vide. Conservez la distinction de facturation : une récupération réussie mais vide coûte quand même un crédit. Une page lointaine vide peut aussi avoir un total inconnu. N'en déduisez ni zéro correspondance dans toute l'archive, ni une raison de demander des pages indéfiniment.
Proposez des actions adaptées à l'échec
Adressez l'erreur à la personne capable d'agir. HTTP 400 invite à vérifier l'entrée réelle, par exemple un paramètre non pris en charge ou une date qui n'est pas au format YYYY-MM-DD. HTTP 401 concerne la clé API du service ; 402, les crédits disponibles sur le compte du service. Aucun des deux ne prouve que la connexion du lecteur à votre application a expiré. L'opérateur peut devoir corriger l'identifiant secret du backend ou examiner le solde. Évitez de demander au lecteur de coller une clé du service dans un écran de recherche public.
Pour 429, respectez Retry-After et réduisez les envois répétés. Pour 502, conservez la requête et proposez un nouvel essai volontaire lorsqu'il convient ; le remboursement des crédits réservés peut attendre une réconciliation. L'absence de réponse exige un autre message : l'issue est inconnue, y compris l'éventuelle facturation d'une requête réussie. Les requêtes invalides rejetées avant réservation ne sont pas facturées, mais une rupture de connexion ne prouve pas ce rejet. L'endpoint gratuit /v1/status fournit une déclaration statique du service et montre qu'il répond en HTTP ; il ne peut ni trancher le sort de la requête perdue ni vérifier le bon fonctionnement de la recherche.
Testez la continuité de navigation
La continuité suppose aussi de préserver les saisies. Prévoyez des cas locaux pour une réponse vide valide, une erreur HTTP et une exception réseau avant qu'une réponse soit disponible. Utilisez des données explicitement synthétiques : ces cas testeraient votre interface, sans établir la disponibilité de l'archive. Vérifiez que chacun produit un message distinct et laisse accessibles les paramètres envoyés. Ajoutez un cas où le lecteur modifie le formulaire pendant une requête en cours : l'ancienne issue ne doit pas apparaître comme une réponse à la nouvelle formulation.
Si la page suivante échoue, conservez les enregistrements déjà chargés et distinguez leur état terminé de cette continuation en échec. Permettez de réessayer cette page ou de revenir au formulaire sans émettre discrètement une autre requête. Ignorer une réponse tardive dans l'interface ne garantit pas l'annulation du travail côté serveur. Indiquez quelles transitions votre application teste réellement et lesquelles restent proposées. L'objectif est un écran qui expose les faits connus et offre une prochaine action utile, plutôt qu'un message rassurant que la réponse ne justifie pas.
