Reportes de fallo y recuperación: el consentimiento y la pantalla de repliegue

Qué hace

Trabajan juntos dos mecanismos. El primero es un límite de error de React colocado alrededor de cada zona protegida de la aplicación. Si un componente de esa zona lanza un error al renderizar, React desmontaría todo el árbol y dejaría una ventana en negro; el límite lo captura, registra el error en la consola con la pila de componentes y renderiza una tarjeta en lugar de la zona. El resto de la aplicación sigue funcionando: el feed de datos y la conexión del bróker quedan intactos.

El segundo es el reportador de fallos. Cuando el límite captura un error de renderizado, o cuando un manejador global ve una promesa rechazada sin gestionar o un error no capturado fuera de React, se compone un reporte y se envía, pero solo si diste tu consentimiento. El ajuste se guarda en local bajo una única clave; si no está, no hay consentimiento. El envío es sin esperar respuesta: la pantalla de error nunca se retrasa por la petición, y un envío fallido falla sin ninguna ventana emergente.

Ajustes

Qué contiene el reporte

La carga útil tiene seis campos: kind (panic para el lado Rust, render para un error de renderizado de React, unhandled para una promesa rechazada o un error no capturado), message, stack, appVersion, platform y la marca de tiempo. El mensaje se corta a 1.000 caracteres y la pila a 4.000, conservando los primeros marcos, que son los que llevan la información.

Antes de entrar en la carga útil, message y stack pasan por un depurador que enmascara claves de API de IA, tokens Bearer y Basic, rutas de usuario de Windows y Unix (acotadas en el separador de ruta, para que un nombre de cuenta de Windows de dos palabras no filtre su segunda mitad), direcciones de correo y pares clave/valor sensibles como password, token, api_key, user_id, unique_user_id, login o account. Un test fija estos patrones con las formas reales que toman en los mensajes de error de la aplicación. Las credenciales del bróker, el nombre de cuenta, las posiciones, el P&L, los símbolos operados y la clave de IA nunca forman parte del reporte.

Un limitador conserva un reporte por firma distinta (kind más los primeros 200 caracteres del mensaje depurado) y como mucho cinco firmas distintas por sesión, de modo que un bucle de renderizado que falla en cada fotograma no genere cientos de peticiones.

Cómo usarlo

• Si una pantalla muestra Esta pantalla se ha detenido, pulsa primero Recargar. Si vuelve a ocurrir, pulsa Copiar los detalles y pega el texto en un reporte desde la pantalla Informar de un problema, que además adjunta automáticamente las últimas líneas de error.
• Activa Reportes de fallo en la página Cuenta si quieres que los errores de renderizado y los no gestionados lleguen a los desarrolladores sin que hagas nada. La etiqueta junto a la casilla dice exactamente qué se envía y qué no.
• La pantalla Informar de un problema es un canal aparte y voluntario, con sus propios mensajes de fallo visibles; el reportador de fallos es automático y silencioso por diseño.

Límites y trampas

• El límite cubre los errores de renderizado de su zona. Los errores en callbacks de eventos, temporizadores e importaciones dinámicas los capturan los manejadores globales, que reportan pero no muestran la tarjeta.
• El consentimiento es una única clave de almacenamiento local en esta máquina; un perfil nuevo, un almacenamiento borrado o uno que la aplicación no pueda leer equivalen a no consentir, así que no se envía nada.
• El reporte se envía al dominio canónico con un tiempo de espera de 5 segundos; si la máquina está sin conexión, el reporte se descarta, no se encola.