Errores de sincronización y objetos duplicados

Para no crear una cuenta duplicada, el servicio de sincronización empareja cada objeto local con uno que ya exista en la nube. Lo hace de dos maneras: por un ancla de origen que identifica al objeto (el emparejamiento fuerte), o por un valor que coincida, como la dirección de correo o el nombre de usuario (el emparejamiento por coincidencia).

La segunda es cómoda cuando se migra una nube que ya tenía cuentas, y es peligrosa por lo mismo: un correo reutilizado después de una baja puede unir a una persona nueva con la cuenta de otra. El riesgo no está en el algoritmo, está en que nadie compare al titular.

Pide SELECT * FROM emparejamientos y revisa quién es el titular de cada lado.

De los cinco emparejamientos nuevos, cuatro unen al mismo titular. Uno no: el objeto local de una persona recién llegada coincidió por correo con la cuenta en la nube de otra, y esa otra cuenta tiene un rol en la nube. Es el tipo de hallazgo que justifica leer las filas y no confiar en el recuento de «sin errores».

Una exportación que borra demasiados objetos de golpe suele detenerse por un umbral de protección contra borrados accidentales. Es un freno bienvenido: una regla mal configurada puede pedir miles de borrados en un ciclo. Pide SELECT * FROM errores_de_sincronizacion y busca el error cuyo estado dice que la exportación se detuvo.

Los errores de conflicto de atributo ocurren cuando dos objetos intentan quedarse con el mismo correo o el mismo nombre de usuario. Se resuelven investigando cuál de los dos objetos es el legítimo, no borrando al azar. Cuenta los de ese tipo que hoy siguen abiertos; los resueltos no cuentan.

El umbral detuvo la exportación. Subirlo y dejar que corra resuelve el aviso, pero no responde a la pregunta de fondo: por qué hay objetos por borrar. Esa unidad organizativa tiene cuentas de personas ya retiradas, y la política de alcance dice que no deberían estar sincronizadas. Antes de mover el umbral hay que entender el origen.