Conectores y qué pasa cuando fallan

Un conector tiene dos trabajos: leer lo que hay y escribir lo que la plataforma decidió. Cuando la lectura falla, el modelo queda con datos viejos. Cuando la escritura falla, las decisiones (crear una cuenta, deshabilitar otra) se quedan en una cola con un contador de intentos. Lo correcto es reintentar, alertar a una persona cuando los intentos pasan de un umbral y no dar por hecha una operación que el sistema no confirmó.

Lo que no se debe hacer es lo cómodo: marcar como completada una operación pendiente para que el tablero se vea limpio.

Cada conector entra al sistema con una cuenta de servicio, y esa cuenta tiene credenciales que caducan o se cambian. Una causa muy común de que un conector deje de ejecutarse es una credencial vencida: nadie la renovó. Para investigar, se cruzan tres cosas: el estado del conector en la tabla conectores, el detalle de lo que falló en errores y la cuenta de servicio que aparece en el mensaje.

Un conector que falla no se nota por el error, se nota por la antigüedad de su último éxito. El número que importa es cuántas horas hace que el sistema no recibe una ejecución correcta, porque dice cuánta realidad se ha acumulado sin reflejarse. La tabla parametros trae el momento del corte y conectores la última ejecución correcta de cada uno.

La tabla cola muestra lo que la plataforma ya decidió y el conector no ha podido escribir. No todas las operaciones pesan igual: una creación atrasada hace esperar a una persona; una baja atrasada deja un acceso abierto que ya no corresponde a nadie. Esa es la operación que se atiende primero.

Un conector puede terminar en tres estados: correcta, fallida y parcial. Parcial significa que terminó pero dejó objetos sin procesar. Es el estado más fácil de ignorar, porque el tablero no se pone en rojo. Pero los objetos que quedaron sin procesar son exactamente los que no se están gobernando.