El bug del evento fosilizado: el aviso que vuelve al rotar

Todo desarrollador de Android ha visto este bug y casi ninguno ha visto su causa. La secuencia es siempre la misma: el usuario introduce mal la contraseña, aparece un aviso de error, el usuario gira el teléfono para verlo mejor y el aviso vuelve a aparecer, ahora sin que nadie haya intentado nada. La reacción típica es tratarlo como una rareza del ciclo de vida, poner un parche que borre el mensaje después de mostrarlo y seguir adelante. Pero no es una rareza ni un accidente de Android: es el comportamiento exactamente correcto de un flujo conflado al que se le ha pedido que transporte algo que no es un valor sino un acontecimiento. El aviso vuelve porque el sistema hace justo lo que prometió hacer. Entender la mecánica —paso a paso, sin metáforas— es lo que convierte este bug en una lección de diseño de tipos en vez de en una anécdota del framework.

La reconstrucción del crimen

El código acusado es inocente a primera vista y es el que casi todo el mundo escribe la primera vez.

data class LoginState(
    val cargando: Boolean = false,
    val error: String? = null,
)

fun entrar(usuario: String, clave: String) = intent {
    reduce { state.copy(cargando = true, error = null) }
    when (val r = repo.login(usuario, clave)) {
        is Ok -> reduce { state.copy(cargando = false) }
        is Fallo -> reduce { state.copy(cargando = false, error = r.mensaje) }
    }
}

Nótese que el código incluso hace algo aparentemente cuidadoso: limpia el campo de error al empezar un intento nuevo. Ese detalle es el que da falsa confianza, porque cubre el único caso que el autor probó —dos intentos seguidos— y deja intacto el que rompe, que no depende de intentos sino del ciclo de vida.

Del lado de la vista, alguien observa state.error y, cuando no es nulo, lanza el aviso. Funciona la primera vez, y esa es justamente la trampa: el bug no se manifiesta hasta que interviene el ciclo de vida. Los actores son tres y conviene nombrarlos con precisión. El ViewModel sobrevive al cambio de configuración: es su razón de existir. Su flujo de estado es un StateFlow, es decir, un flujo conflado que mantiene siempre un valor actual y lo entrega inmediatamente a cualquier suscriptor nuevo. La vista, en cambio, se destruye y se vuelve a crear.

Merece la pena subrayar que ninguno de los tres actúa mal. El ViewModel sobrevive porque para eso se inventó, y si no sobreviviera perderíamos la petición en vuelo al girar. El flujo reemite porque su contrato es que quien se suscriba obtenga inmediatamente el valor vigente, y si no lo hiciera la pantalla nueva aparecería vacía tras la rotación. La vista muestra el aviso porque encuentra un campo no nulo, que es la única información de la que dispone. Tres comportamientos correctos componen un fallo: esa es la firma inconfundible de un error de modelado y no de implementación.

Ahora la secuencia. El login falla y el estado pasa a contener error con el mensaje. La vista lo observa y muestra el aviso. El usuario gira el teléfono: la vista muere, el ViewModel no. La vista nueva se suscribe al mismo StateFlow y este, cumpliendo su contrato, le entrega de inmediato el último valor —que sigue conteniendo el mensaje de error, porque nadie lo ha cambiado—. La vista nueva ejecuta la misma lógica que la vieja: el campo no es nulo, luego muestra el aviso. Segundo aviso, sin segundo intento de login.

sequenceDiagram
participant VM as ViewModel que sobrevive
participant SF as StateFlow conflado
participant V1 as Vista original
participant V2 as Vista tras rotar
VM->>SF: reduce con error igual a sin conexion
SF->>V1: emite estado con error
V1->>V1: muestra el aviso una vez
V1--xV1: la rotacion destruye la vista
V2->>SF: se suscribe de nuevo
SF->>V2: reemite el ultimo estado con el mismo error
V2->>V2: muestra el aviso otra vez sin causa

Tres disparadores, una sola causa

La rotación es el caso didáctico, pero no el único ni el más frecuente en producción. Hay tres puertas por las que entra el mismo fallo, y todas comparten mecanismo: alguien vuelve a suscribirse a un flujo que retiene el pasado.

Hay una cuarta puerta más rara y más dañina, que aparece cuando dos pantallas observan el mismo ViewModel compartido —típico en flujos con panel lateral, en pantallas grandes con lista y detalle, o en una barra inferior con estado común—. Ahí el evento fosilizado no se muestra dos veces en el tiempo sino dos veces en el espacio: ambas vistas leen el mismo campo y ambas ejecutan la orden, de modo que el usuario recibe dos avisos simultáneos o dos navegaciones apiladas. Ninguna cantidad de borrado posterior arregla algo que ya se ejecutó por duplicado.

La causa común es una sola y merece enunciarse como teorema: un valor retenido en un flujo conflado se entrega tantas veces como suscripciones haya. No es un fallo del flujo; es su contrato, y es exactamente lo que queremos para el estado real. El nombre del usuario debe volver tras rotar. El indicador de carga debe volver. El problema no está en la reemisión sino en haber metido dentro de la fotografía algo que era un disparo.

Por qué los parches históricos no bastan

La industria intentó resolverlo sin tocar la categoría del dato, y el resultado es un museo de epiciclos que conviene conocer para no reinventarlos.

Todos comparten una forma y conviene reconocerla antes de estudiarlos uno a uno: aceptan que el evento viva en el estado y añaden un mecanismo auxiliar que simule el olvido. Es exactamente la estrategia de los epiciclos en astronomía —salvar el modelo añadiendo correcciones en vez de cambiar la premisa— y tiene su mismo destino: cada parche cubre el caso que motivó su invención y falla en el siguiente.

La bandera con borrado manual es el primero: después de mostrar el aviso, la vista llama a un método que pone el campo a nulo. Funciona en el caso feliz y falla en todos los demás. Introduce una escritura de la vista sobre el estado, invierte el flujo unidireccional que la arquitectura existía para garantizar, y abre una carrera: si la vista se destruye entre mostrar y borrar, el evento sobrevive. Con dos observadores simultáneos, el primero en borrar deja al segundo sin evento.

// Epiciclo tipico: envoltorio con marca de consumido
class Evento<out T>(private val contenido: T) {
    private var consumido = false
    fun tomarSiNoConsumido(): T? =
        if (consumido) null else { consumido = true; contenido }
}

El envoltorio con marca de consumido es más sofisticado y no cambia la naturaleza del problema: mete estado mutable dentro de un objeto que viaja por un flujo de valores inmutables, rompe la comparación por igualdad que hace eficiente al modelo declarativo, y sigue sin definir qué ocurre con varios coleccionistas. SingleLiveEvent hizo lo mismo a nivel de contenedor observable y arrastró su propia limitación conocida: solo entrega al primer observador y pierde silenciosamente el evento si no hay ninguno activo.

Hay un tercer parche, más moderno y más engañoso, que consiste en comparar el estado nuevo con el anterior y disparar el aviso solo cuando el campo cambia. Falla por dos sitios. Primero, tras una rotación no hay estado anterior con el que comparar: la vista es nueva y su primera lectura es siempre un cambio. Segundo, dos errores idénticos consecutivos —el mismo mensaje dos veces— no producen ningún cambio de valor, así que el segundo aviso no se muestra. El parche de la comparación falla en las dos direcciones a la vez: muestra de más cuando no debe y de menos cuando debe.

El mismo bug fuera de Android

Ayuda mucho comprobar que esto no es una peculiaridad de una plataforma sino un patrón que reaparece en cualquier sistema con un modelo observable y una vista que se reconstruye.

Que el mismo error aparezca en cuatro ecosistemas con paradigmas distintos, escritos por comunidades que no se leen entre sí, es la evidencia más fuerte de que la causa no está en ninguno de ellos. Lo que comparten los cuatro no es una librería sino una premisa: hay un modelo observable y hay una vista que puede reconstruirse a partir de él. En cuanto se acepta esa premisa —y hay que aceptarla, porque es lo que hace manejable una interfaz moderna—, meter una orden dentro del modelo produce el fantasma inevitablemente.

La comparación con Elm es la más instructiva porque enseña que el problema tiene una solución de diseño y no solo de fontanería. Allí la función de actualización devuelve un par: el modelo nuevo y una descripción del trabajo a realizar. El trabajo no cabe dentro del modelo porque son cosas de tipos distintos, y por eso ningún programador de Elm ha visto nunca un aviso que reaparece al redimensionar la ventana. La arquitectura no le pide disciplina: le impide expresar el error.

// La forma del error, independiente del framework
// El campo describe una ORDEN, no un HECHO, y por eso reaparece
data class Pantalla(val debeNavegarAHome: Boolean)

// La forma correcta: el hecho se queda, la orden se va por otro sitio
data class Pantalla2(val sesionIniciada: Boolean)

Las dos declaraciones parecen equivalentes y no lo son. debeNavegarAHome es una orden congelada: nombra lo que la vista tiene que hacer, y como el estado se relee, la orden se vuelve a leer y a cumplir. sesionIniciada es un hecho: describe el mundo, se puede releer mil veces y no ordena nada. El nombre del campo es, casi siempre, el mejor detector del bug: si un campo del estado se llama debe, mostrar, ir o disparar, ya está mal clasificado antes de que exista la lógica que lo lee.