Triaje de caídas y regresiones

Triar un fallo de fuzzing es contestar, en orden, unas pocas preguntas. ¿Es un duplicado? Si comparte firma con otro, se agrupa. ¿Es una regresión? Si no ocurría en la última versión publicada, lo introdujo un cambio reciente y todavía no ha llegado a los clientes: es la que más urge frenar. ¿Es alcanzable desde la interfaz pública? Si solo lo provoca una función interna o una rama sin conectar, importa menos hoy. Y por último, ¿qué hace al fallar? Una excepción controlable es menos grave que una pérdida de memoria o un bloqueo sin límite.

Dos avisos con la misma firma son el mismo fallo: la misma función y el mismo tipo de excepción. Un duplicado es útil como dato (dice cuántas veces se vuelve a encontrar), pero no es trabajo nuevo. La tabla de caídas trae nueve avisos; el trabajo se mide por las causas.

Abre triaje/caidas.csv.

Una regresión es un fallo que aparece tras un cambio: no reproduce en la última versión publicada pero sí en el desarrollo actual. Si además la provoca una entrada que llega por la API pública, los clientes lo sufrirán cuando salga la siguiente versión. Es la prioridad: todavía se está a tiempo de evitar que se publique.

Cruza la tabla de caídas con triaje/versiones.txt, que dice qué funciones llega a tocar un cliente.

La bisección repite la prueba en versiones intermedias del historial hasta encontrar el primer cambio donde el fallo aparece. El equipo la hizo con la entrada minimizada de la regresión. Conocer el cambio ahorra tiempo: se lee solo esa diferencia, y su autor suele recordar qué suposición hizo.

Abre triaje/biseccion-C-103.txt.

Un fallo arreglado sin prueba puede volver en la próxima reescritura. La entrada minimizada que lo provocaba es la mejor prueba de regresión posible: pequeña, concreta y capaz de fallar si el fallo regresa. El arreglo y la prueba entran juntos en el mismo cambio, y la entrada se añade al conjunto de fallos guardados que la corrida corta de cada solicitud de cambio vuelve a ejecutar.