Rapports de plantage et reprise après erreur : l'opt-in et l'écran de repli

Ce que ça fait

Deux mécanismes fonctionnent ensemble. Le premier est une barrière d'erreur React placée autour de chaque zone protégée de l'application. Si un composant de cette zone lève une erreur au rendu, React démonterait sinon tout l'arbre et laisserait une fenêtre noire ; la barrière l'intercepte, journalise l'erreur dans la console avec la pile de composants et rend une carte à la place de la zone. Le reste de l'application continue de tourner : le flux de données et la connexion broker ne sont pas touchés.

Le second est le rapporteur de plantage. Quand la barrière intercepte une erreur de rendu, ou qu'un gestionnaire global voit un rejet de promesse non géré ou une erreur non interceptée hors de React, un rapport est assemblé et envoyé, mais seulement si vous avez consenti. Le réglage est stocké en local sous une clé unique ; son absence signifie pas de consentement. L'envoi est du « tire et oublie » : l'écran d'erreur n'est jamais retardé par la requête, et un envoi raté échoue sans aucune fenêtre surgissante.

Réglages

Ce que contient le rapport

La charge utile comporte six champs : kind (panic côté Rust, render pour une erreur de rendu React, unhandled pour une promesse rejetée ou une erreur non interceptée), message, stack, appVersion, platform et l'horodatage. Le message est coupé à 1 000 caractères et la pile à 4 000, en gardant les premières frames, celles qui portent l'information.

Avant d'entrer dans la charge utile, message et stack passent par un purgeur qui masque les clés d'API IA, les jetons Bearer et Basic, les chemins utilisateur Windows et Unix (bornés au séparateur de chemin, pour qu'un nom de compte Windows en deux mots ne laisse pas fuiter sa seconde moitié), les adresses e-mail et les paires clé/valeur sensibles comme password, token, api_key, user_id, unique_user_id, login ou account. Un test fige ces motifs avec les formes réelles qu'ils prennent dans les messages d'erreur de l'application. Les identifiants broker, le nom de compte, les positions, le P&L, les symboles tradés et la clé IA ne font jamais partie du rapport.

Une limitation garde un rapport par signature distincte (kind plus les 200 premiers caractères du message purgé) et au plus cinq signatures distinctes par session, de sorte qu'une boucle de rendu qui lève une erreur à chaque frame ne produit pas des centaines de requêtes.

Comment l'utiliser

• Si un écran affiche Cet écran s'est interrompu, cliquez d'abord Recharger. Si cela se reproduit, cliquez Copier le détail et collez le texte dans un signalement depuis l'écran Signaler un problème, qui joint aussi automatiquement les dernières lignes d'erreur.
• Activez Rapports de plantage sur la page Compte si vous voulez que les erreurs de rendu et non gérées parviennent aux développeurs sans action de votre part. Le libellé à côté de la case indique exactement ce qui est envoyé et ce qui ne l'est pas.
• L'écran Signaler un problème est un canal distinct et volontaire, avec ses propres messages d'échec visibles ; le rapporteur de plantage est automatique et silencieux par conception.

Limites et pièges

• La barrière couvre les erreurs de rendu de sa zone. Les erreurs dans les rappels d'évènements, les minuteries et les imports dynamiques sont interceptées par les gestionnaires globaux, qui rapportent mais n'affichent pas la carte.
• Le consentement est une clé unique de stockage local sur cette machine ; un profil neuf, un stockage vidé ou un stockage illisible signifient tous pas de consentement, donc rien n'est envoyé.
• Le rapport est envoyé au domaine canonique avec un délai de 5 secondes ; si la machine est hors ligne, le rapport est abandonné, pas mis en file.