Leer los resultados de una caza

Una caza (hunt) aplica una misma recolección a muchos clientes a la vez, según la documentación de la herramienta. Cada cliente que se conecta mientras la caza está abierta recibe la pregunta, la ejecuta y devuelve sus filas; los que no se conectan en ese tiempo no la reciben. Por eso el resultado de una caza tiene dos mitades: lo que devolvieron los que contestaron y la lista de los que no.

Leer una caza empieza por el estado por cliente: cuántos completaron con filas, cuántos completaron sin filas, cuántos no respondieron y cuántos fallaron. Solo después se leen las filas.

Un equipo apagado, fuera de la red o con un fallo no entrega resultado, y nada en sus filas lo distingue de uno limpio si solo se mira el total de coincidencias. Por eso el número que importa para declarar los límites de la caza es el de equipos sin resultado: los que no respondieron más los que terminaron con error.

Ese número no viene escrito como tal en la tabla de estados: se obtiene sumando los estados que no son un resultado válido.

Entre las filas devueltas, casi todas se parecen: la misma tarea, el mismo ejecutable, el mismo firmante, creadas en minutos seguidas. Eso es un despliegue de software. Lo que merece atención es la fila que no encaja con las demás: otra ruta, sin firma, un usuario concreto. No es una conclusión, es una prioridad de lectura.

La pregunta de la tarea es solo de lectura: cuál de las once filas rompe el patrón de las otras.

Los clientes con error empezaron la recolección y no la terminaron: pueden haber devuelto algunas filas o ninguna, y el motivo importa. Un acceso denegado a una ruta puede significar un permiso que falta o una protección que alguien puso. Un tiempo límite superado puede ser un equipo lento o una consulta demasiado pesada para él.

Contar un equipo con error como limpio es el error de lectura más caro de una caza: se afirma una ausencia que no se comprobó.