Error Handling

Cuando una petición falla, reintentar inmediatamente sobrecarga el servidor. El backoff exponencial (1s, 2s, 4s, 8s...) reduce la presión y da tiempo de recuperación. La UI debe mostrar el conteo regresivo y permitir reintento manual antes del timeout.

Cuando un componente falla en cargar, la pantalla no puede quedarse en blanco. Siempre mostrar contenido de reemplazo: la última versión en caché, un skeleton con datos ficticios, o un mensaje de error con acción. Una pantalla vacía comunica que la app se rompió; un fallback comunica que es temporal.

En operaciones por lotes (enviar 10 emails, subir 5 archivos), una falla parcial no significa falla total. Mostrar simultaneamente qué tuvo éxito y qué falló, con acciones diferenciadas. Nunca reportar éxito total si algo falló, ni bloquear todo por un fallo puntual.

Todo error debe ofrecer al menos dos caminos de salida: uno automático (reintentar) y uno manual (ir a un estado seguro conocido). El usuario nunca debe quedar atrapado sin salida. Los mensajes de error deben decir qué pasó, por qué, y exactamente qué hacer a continuación.